Random number generating apparatus for an interface unit of a carrier sense with multiple access and collision detect (CSMA/CD) ethernet data network

ABSTRACT

A random number generating apparatus for an interface unit of a Carrier Sense with Multiple Access and Collision Detect (CSMA/CD) Ethernet data network. The interface unit includes a transmit backoff unit for implementing a backoff algorithm in response to a network collision signal and a random number. The apparatus comprises a dual mode random number generator and a multiplexer for switching the random number generator between modes in accordance with the serial address bits of a data packet being processed by the interface unit. The random number generator includes a 25 stage linear feedback shift register. The multiplexer has two signal inputs connected to outputs of the 18th and 22nd stages of the shift register respectively, a switch input connected to receive the serial address bits and an output connected in circuit to an input of the shift register.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 08/141,194 filed Oct. 21, 1993, which issued asU.S. Pat. No. 5,625,825 on Apr. 29, 1997.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to the art of circuits andsystems comprising electrical shift registers using a particular code orcounting sequence, and more specifically to a random number generatingapparatus for an interface unit of a Carrier Sense with Multiple Accessand Collision Detect (CSMA/CD) Ethernet data network.

2. Description of the Related Art

Electronic data networks are becoming increasing widespread for thecommunication of divergent types of data including computer coded textand graphics, voice and video. Such networks enable the interconnectionof large numbers of computer workstations, telephone and televisionsystems, video teleconferencing systems and other facilities over commondata links or carriers.

Computer workstations are typically interconnected by local areanetworks (LAN) such as Ethernet, Token Ring, DECNet and RS-232, whereasmetropolitan, national and international systems are interconnected bywide area networks (WAN) such as T1, V3.5 and FDDI.

LANs and WANs themselves can be interconnected by devices known as hubs,bridges and routers in an unlimited configuration. Although thedistinction between these interconnection devices is becomingincreasingly arbitrary, they are officially classified in accordancewith the layer in the Open Systems Interconnection (OSI) model in whichthey operate.

Hubs interconnect devices using the Physical Layer, bridges utilize theData Link layer whereas routers operate using the Network layer. Hubsand bridges generally act merely as switches or funnels, whereas routersperform higher level functions including selecting optimal routesthrough the network for transmission of data packets or cells on anindividual basis, and performing network management tasks such asforcing diagnostics operations and controlling other routers or nodes.Whereas hubs and bridges generally operate on data which is formatted ina single protocol such as those listed above (uniprotocol), routers cantypically identify and process data which can be in any one of severalprotocols (multiprotocol).

Interconnect devices, especially the more sophisticated routers, havetypically been large, bulky and expensive units which operate atrelatively low speed. As such, they limit the data throughput speed inthe network in which they are installed. The reasons why routers havebeen so slow is that they are generally multichip units which transferdata being processed to and from Content Addressable Memory (CAM) chipswhich are separate from the processor, input/output (I/O) and otherfunctional chips of the unit.

These transfer operations each require multiple system clock cycleswhich fundamentally limit the transfer speed. In addition, multiplelatencies are present in the various paths by which data moves throughthe unit. The degree by which such latencies can be reduced, as well asthe degree by which the size and cost of a multichip system can bereduced, are also fundamentally limited.

Ethernet is a network protocol embodying IEEE standard 802.3, which ismore generically referred to as Carrier Sense with Multiple Access andCarrier Detect (CSMA/CD). Ethernet cores used in hubs and other devicescomprise transmit backoff units which execute a truncated exponentialbackoff algorithm in response to a sensed collision condition (two ormore nodes attempting to transmit data simultaneously). This algorithmutilizes a pseudo random number generator to generate a random numberwhich designates a backoff time, or a time for which the transmit engineof the core should wait before attempting transmission.

If all of the cores in the network utilize the same type of pseudorandom number generator, they will generate the same sequence of randomnumbers. If the random number generators of two or more cores becomesynchronized with each other, they will cause the associated cores toback off by the same times. This will cause the cores to continuouslyattempt to transmit at the same times. This condition is called"lockup", and can result in the cores generating collisionsindefinitely, preventing any data from being transmitted over thenetwork.

Asynchronous Transfer Mode (ATM) is a network protocol which is highlyadvantageous in that it enables high speed transmission of divergenttypes of data, including codes, video and voice. This is accomplished bybreaking down the data to be transmitted into cells including 48 bitConversion Sublayer Payload Data Unit (CS-PDUs) which contain the actualdata, and a header and trailer. ATM can also be utilized as a universalprotocol, replacing the protocols which are currently in use and arespecific to LANs or WANs.

The header contains a virtual channel identifier and a virtual pathidentifier which identify the particular cell and its intendeddestination, and specify an optimal path through the network throughwhich the cell should be routed to reach its destination. The header canalso include numerous other information such as the type of data in theCS-PDU and attributes of the data, the sender and/or the destination.

The physical limitations discussed above regarding routers in generalalso applies to ATM routers, adapters and termination devices whichinterconnect an ATM network to a network node using a different protocol(or to a host such as a computer workstation). A major problem which isinhibiting the widespread deployment of ATM is that no single ATMprotocol has been developed. A diverse assortment of ATM protocols havebeen developed by various manufacturers throughout the industry, some ofwhich are so different as to be incompatible with each other. At least,the difference between protocols prevents the various higher levelcapabilities of the individual protocols from being universallyutilized.

Congestion is a problem in all networks. This occurs when a large numberof users feed data into the network at the same time. ATM cells need notbe contiguous, so that computer coded data from one user can beinterspersed with, for example, voice data from another user in a timedivisioned manner. However, if too many users attempt to inject too muchdata into the network simultaneously, the bandwidth of the network canbe exceeded resulting in substantial delays in data transmission,transmission errors and lost data.

Congestion is controlled by sensing the traffic in the network at thevarious nodes, sending special information packets between nodes tonotify the other nodes of the magnitude and type of congestion, anddelaying transmission of data at specified nodes in accordance with apredetermined congestion control algorithm.

ATM networks are relatively new, and the nature and patterns whichcongestion can take are not well understood. This makes it difficult toformulate and implement an effective congestion control algorithm.Similar to the variety of ATM protocols which are currently in use, anumber of divergent congestion control algorithms have been devised andplaced into service.

ATM routers, termination devices and other network elements arehardwired with the particular manufacturer's protocol and congestioncontrol algorithm. Although it is likely that a universal ATM standardwill be developed in the near future the multiprotocol problem will beeliminated, ATM systems will have to accommodate newly developedcongestion control algorithms for an extended period of time until thenature of congestion can be well understood and handled. In themeantime, any changes to existing ATM systems require hard retooling,which is extremely time consuming and expensive.

SUMMARY OF THE INVENTION

An asynchronous transfer mode (ATM) processing system interconnection ortermination unit embodying the present invention is implemented on asingle integrated circuit chip. The unit includes a Virtual ChannelMemory (VCR) for storing ATM cells for segmentation and reassembly, aDirect Memory Access (DMA) controller for interconnecting the VCR to ahost unit, and a Parallel Cell Interface (PCI) for interconnecting theVCR to an ATM network.

A Reduced Instruction Set Computer (RISC) microprocessor controls theDMA controller as well as segmentation and reassembly of ConversionSublayer Payload Data Unit (CD-PDU)s and transfer between the memory,the host and the ATM network and other operations of the device usingsingle clock cycle instructions. The operating program for the RISCmicroprocessor is stored in a volatile Instruction Random Access Memory(IRAM) in the form of firmware which is downloaded at initialization.The program can be user designed to accommodate changes in ATM networkprotocols and congestion handling routines.

A Pacing Rate Unit (PRU) includes a global pacing rate register whichautomatically reduces the maximum transmission rate of ATM cells inresponse to a sensed congestion condition in the ATM network.

The ATM termination unit is being manufactured on a commercial basis asthe ATMizer™ by LSI Logic Corporation of Miltipas, Calif. The ATMizer'suniqueness and the power of its architecture are derived from theinclusion of a 32 bit MIPS RISC CPU on chip.

The ATMizer is implemented on a single chip, thereby eliminating theoff-chip memory access delays and latencies involved in conventionalnetwork interconnect devices. Such integration enables the ATMizer tooperate at substantially higher speeds than conventional devices. TheATMizer chip can be easily plugged into a socket in highly divergenttypes of network and host devices, thereby providing a highly desirableand cost-efficient replacement for conventional large, expensive andinflexible network interconnects.

It will be further appreciated that the scope of the invention includesembodying the present ATM interconnect device as a hub, bridge,uniprotocol or multiprotocol router, or in any other configurationregarding ATM termination, switching or routing. The single chip ATMizerconcept also includes incorporating the ATMizer per se on a single chipwhich can include other elements, such as a host processor. The conceptalso includes any single chip device which integrates an ATM deviceembodying the present invention thereon.

It can be expected that ATM standards and/or congestion controlalgorithms will become universalized at some time in the future. Whenthis occurs, some or all of the functions of the ATMizer's RISCmicroprocessor and/or volatile firmware memory can be replaced withhardwired or otherwise fixed options. It will be understood the scope ofthe invention includes reconfiguring the computing and control functionsof the ATMizer with a microcontroller, non-volatile memory, hard wiredcircuitry, or any combination thereof.

While the basic function of the ATMizer is to provide for thesegmentation and reassembly (and ATM cell generation) of ATM AdaptationLayer 1 data streams and ATM Adaptation Layers 2, 3/4 and 5 CS-PDUs, itson-chip processor allows user firmware to accomplish these tasks in sucha controlled fashion such that segmentation and reassembly are just twoof the many functions that the ATMizer can perform.

The features of the present ATMizer include fulfilling the followingobjects.

SCATTER-GATHER DMA

CS-PDUs under segmentation need not be contiguous in system memory whenusing the ATMizer. The Segmentation and Reassembly routines, written bythe system designer and executed by the ATMizer, can performsegmentation on non-contiguous data structures that logically form asingle CS-PDU. This is what is commonly referred to as the "gather"function of a scatter-gather DMA controller.

These user supplied routines handle AAL and ATM header generation andextraction as well as link list pointer management and bufferallocation. The implications of "scatter" and "gather" support, madepossible by the inclusion of a 32 bit CPU (referred to throughout thespecification as the APU or ATM Processing Unit) are significant anddescribed in the detailed description portion of the specification.

APPLICATION ACCELERATION THROUGH HEADER STRIPPING AND DATA ALIGNMENT

In specialty applications, the ATMizer can be saddled with theresponsibility of stripping higher layer headers from incoming CS-PDUsand placing them in specific memory locations to aid network software.In addition, the ATMizer can utilize the powerful byte alignmentcapabilities of its DMA engine to insure that the user data payloadportion of the higher layer PDU (Transport Layer) is written into memoryon a word aligned basis. This releases application layer software fromthe responsibility of insuring proper data alignment.

CELL SWITCHING

The ATMizer enables a system to either terminate all VCs or terminatesome but switch others, simultaneously. On a per VC basis the APU canmake a determination as to whether it should reassemble the SARUser-Payload into a CS-PDU or simply pass the entire cell, headers andtrailers intact, to some other memory mapped ATM port or ATM switchinterface.

The ATMizer can even switch cells between its Receiver and Transmitterwithout touching system memory. This structure can be put to use inring, dual and triple port switching fabrics, and other topologies. Incell switching situations, the VCI, the VPI both or neither can beselectively translated.

Multicast expansion can be selectively performed. The APU can make thesedecisions in real time and perform the operations. Furthermore, inswitching applications, the ATMizer can support a "user cell size" of upto 64 bytes. This allows the user to pre-pend up to 12 bytes ofswitch-specific information to each cell.

CONGESTION CONTROL

The manner in which congestion will develop in ATM based networks, whatit look like, and how an end station should react to congestion arequestions that cannot be answered because no one has seen enough ATMnetworks in operation to gain a real life understanding of ATM networkcongestion. As the industry moves ahead with ATM so rapidly, theATMizer, with its user programmable CPU positioned directly at the ATMline interface, is capable of executing or facilitating almost anycongestion control algorithm imaginable.

Because its user generated firmware is downloaded at system reset,systems in the field can be updated with new congestion controlalgorithms as more is learned about congestion in real ATM networks.

The ATMizer offers fast congestion response time. Cells arriving at theATMizer's ATM port side with notification of network congestion canaffect the transmission of the very next cell, either inhibiting italtogether, slowing down the rate of transmission of assigned cells orforcing CLP reductions. With a user supplied algorithm, the ATMizerprovides the hardware pacing logic, aggregate traffic shapingcapability, and the processor to execute the algorithm.

AAL1 REAL-TIME DATA STREAMS

The APU in the ATMizer can implement data transfers with real-time datastream buffers (DS1, voice, video, etc.), and transfer data from thedata stream to main memory. Residual Time Stamps are now required aspart of the AAL1 SAR Header. The AAL1 segmentation routine running onthe APU can access RTS values from any memory mapped device or locationand carefully interleave the RTS value into the headers of the AAL1 cellstream. When a new RTS value is needed, the APU retrieves it. Whensequence numbers and sequence number protection are called for, the APUgenerates and inserts the appropriated information into the SAR header,and on reassembly, the APU will verify sequence number integrity andsequentially and pass RTS values to the appropriate devices.

DIAGNOSTIC OPERATION

The ATMizer can actively participate in diagnostic operations utilizingdiagnostic firmware downloaded at system reset. In diagnostic mode, theATMizer can perform functions including forcing HEC, CRC10 and CRC32errors, gather line statistics, and more. Under normal operatingconditions, the APU can be chartered with the additional task ofstatistics gathering to aid in the network management process. All ofthese operations are made possible by the inclusion of the APU.

An adaptive error detection and correction apparatus for an AsynchronousTransfer Mode (ATM) network device such as the ATMizer comprises asensing unit for sensing a congestion condition in the ATM network and aglobal pacing rate unit for adaptively reducing a maximum allowabletransmission ratio of ATM cells containing information to idle ATM cellsin response to a sensed congestion condition.

A processor stores a number corresponding to a relatively high maximumallowable transmission ratio in the global pacing rate register in theabsence of a sensed congestion condition, and stores a numbercorresponding to a relatively low maximum allowable transmission ratioin the global pacing rate register in response to a sensed congestioncondition.

A controller adjusts the maximum allowable transmission ratio inaccordance with the number stored in the global pacing rate register. Aplurality of peak pacing rate counters reset to predetermined valuesupon decrementation to zero, the predetermined values corresponding toservice intervals for segmentation of Conversion Sublayer Payload DataUnit (CD-PDU)s. The processor further comprises means for assigning thecounters to selected CD-PDUs, and sensing the counters to determinewhether or not segmentation of said selected CD-PDUs is within therespective service intervals. The apparatus further comprises a channelgroup credit register having bits corresponding to the respectivecounters.

A random number generating apparatus for an interface unit of a CarrierSense with Multiple Access and Collision Detect (CSMA/CD) Ethernet datanetwork comprises a transmit backoff unit for implementing a backoffalgorithm in response to a network collision signal and a random number.The apparatus comprises a dual mode random number generator and amultiplexer for switching the random number generator between modes inaccordance with the serial address bits of a data packet being processedby the interface unit.

The random number generator includes a 25 stage linear feedback shiftregister. The multiplexer has two signal inputs connected to outputs ofthe 18th and 22nd stages of the shift register respectively, a switchinput connected to receive the serial address bits and an outputconnected in circuit to an input of the shift register.

A single chip router for a multiplex communication network comprises apacket memory for storing data packets, a Reduced Instruction SetComputer (RISC) processor for converting the packets between a LocalArea Network (LAN) protocol and a Wide Area Network (WAN) protocol, aLAN interface and a WAN interface. A Direct Memory Access (DMA)controller transfers packets transferring packets between the packetmemory and the LAN and WAN interfaces.

A packet attribute memory stores attributes of the data packets, and anattribute processor performs a non-linear hashing algorithm on anaddress of a packet being processed for accessing a correspondingattribute of said packet in the packet attribute memory. An addresswindow filter identifies the address of a packet being processed byexamining only a predetermined portion of said address, and can comprisea dynamic window filter or a static window filter.

A single chip hub for an electronic communication network comprises apacket memory for storing data packets, a Reduced Instruction SetComputer (RISC) processor for processing the packets, and a plurality ofmedia access interfaces. A Direct Memory Access (DMA) controllertransfers packets transferring packets between the packet memory and theinterfaces. The hub further comprises an attribute processor and awindow filter which correspond to those of the router.

These and other features and advantages of the present invention will beapparent to those skilled in the art from the following detaileddescription, taken together with the accompanying drawings, in whichlike reference numerals refer to like parts.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a hypothetical electronic data networkincorporating elements of the present invention;

FIG. 2 is a diagram illustrating the organization of the main functionalunits of an asynchronous transfer mode (ATM) termination unit orATMizer™ embodying the present invention;

FIG. 3 is a diagram illustrating the ATM layers which can be addressedby the ATMizer;

FIG. 4 is a block diagram of the ATMizer;

FIGS. 5a and 5b are diagrams illustrating application examples of theATMizer;

FIG. 6 is a diagram illustrating sample VCR software structures for cellholding and on-chip channel support for segmentation;

FIG. 7 is a diagram illustrating a sample channel parameter entrystructure for receive channels;

FIG. 8 is a diagram illustrating Peak Rate Pacing Counters and a ChannelGroup Credit Register of the ATMizer;

FIG. 9 is a diagram illustrating a global pacing rate control functionof the ATMizer;

FIG. 10 is a diagram further illustrating the Pacing Rate Unit;

FIG. 11 is a diagram illustrating a DMA controller of the ATMizer;

FIG. 12 is a diagram illustrating a "store word" function;

FIG. 13 is a diagram illustrating a second "store word" function;

FIG. 14 is a diagram illustrating a "load word" function;

FIG. 15 is a diagram illustrating local address pointers;

FIG. 16 is a diagram illustrating a Parallel Cell Interface as includingATM port side Transmitter and Receiver functions;

FIG. 17 is a diagram illustrating received cell handling options in adual port switch/termination station of the ATMizer;

FIG. 18 is a general signal timing diagram of the ATMizer;

FIG. 19 is a diagram illustrating how a System Control Register isprogrammed using a Store Word instruction;

FIG. 20 is a memory map of the ATMizer;

FIG. 21 is a flowchart illustrating an IDLE loop of the ATMizer;

FIG. 22 is a diagram of the ATMizer in a system supporting AAL 1 and AAL5 circuit termination and cell switching;

FIG. 23 is a diagram illustrating AAL1 circuit emulation and databuffering as performed by the ATMizer 50;

FIGS. 24 and 25 are diagrams illustrating AAL 5 CD-PDU segmentation;

FIG. 26 is a diagram illustrating a cell generation data path;

FIG. 27 is a pin diagram of the ATMizer;

FIG. 28a is a diagram listing the interfacing timing signals of theATMizer;

FIGS. 28b and 28c are timing diagrams illustrating PCI TransmitterSynchronization.

FIG. 28d is a timing diagram illustrating a DMA write operation;

FIG. 28e is a timing diagram illustrating a DMA read operation;

FIG. 28f is a timing diagram illustrating a Parallel Port writeoperation; and

FIG. 28g is a timing diagram illustrating a Parallel Port readoperation;

FIG. 29 is a schematic diagram of an Ethernet controller according tothe present invention;

FIG. 30 is a functional block diagram of a core of the controller ofFIG. 29;

FIG. 31 is an electrical schematic diagram of a random number generatorof the core of FIG. 30;

FIG. 32 is a diagram illustrating a multiprotocol or uniprotocol singlechip router;

FIG. 33 is a diagram illustrating a dynamic window filter;

FIG. 34 is a diagram illustrating a static window filter;

FIG. 35 is a diagram illustrating an example of static window filtering;

FIG. 36 is a diagram illustrating an example of a single chip router asfabricated on a substrate; and

FIG. 37 is similar to FIG. 36, but illustrates a single chip hub.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a hypothetical data communications network 10 towhich the present invention relates. The network 10 comprises a publicservice telephone network (PSTN) 12 which is generally represented as acloud and interconnects users nationally and internationally using acombination of land lines and satellite links.

Although not illustrated in detail, the PSTN 12 comprises a number ofmultiprotocol routers which are capable of interconnecting network nodesusing a variety of Wide Area Network (WAN) protocols, including T1, V.35and FDDI. Asynchronous Transfer Mode (ATM) is a universal protocol whichcan be used for both WANs and Local Area Networks (LAN).

As illustrated in the exemplary network, the PSTN 12 is connectedthrough an ATM link 14 to an end user such as a computer workstation 16through an ATM termination device 50. The PSTN 12 is also connectedthrough an ATM link 18 and a device 50 to a router 18, which in turn isconnected to Ethernet hubs 22 and 24 through an Ethernet LAN network.The hubs 22 and 24 are connected to workstations 16 through the EthernetLAN.

Although the workstations are collectively designated as 18, they neednot be similar, but can individually be constituted by diverse types ofelectronic communication devices such as telephone switching stations,commercial data collections terminals such as automatic bank tellermachines, video and/or voice communication devices.

Further illustrated in the exemplary network 10 is a multiprotocolrouter 26 which is connected to the PSTN 12 through a wide area networklink 28. The router 26 is connected to a Token Ring LAN hub 30 and aNovell LAN hub 32 through respective LAN interfaces. The hubs 30 and 32are connected to workstations 32.

The device 50 is being commercially manufactured as the ATMizer™, andhas been designed to control almost all aspects of ATM line operationfrom segmentation and reassembly of CS-PDUs and real-time data streams,to cell switching. Scatter-gather DMA, ATM layer operations, congestioncontrol, statistics gathering, messaging, error monitoring, anddiagnostic troubleshooting of the ATM port are all under APU control.

In addition to Segmentation and Reassembly, the single chip ATMizer 50allows active and intelligent control of all aspects of ATM stationoperation. The provision of high speed processing capabilities at theport interface allows for the implementation of systems that can delivera level of operational control that can not be cost effectivelydelivered in a discrete implementation.

The ATMizer 50 will now be described in detail.

INDEX

1.0 ATMizer Features

1.1 General Features

1.2 ATM Adaptation Layer Features

1.3 ATM Layer Features

1.4 ATM Port Physical Interface Features

1.5 Diagnostic Support Features

2.0 Operations Performed by the ATMizer

3.0 The ATMizer--Functional Blocks

3.1 The ATMizer Processing Unit (APU)

3.2 1024×32 Instruction RAM (IRAM)

3.3 The Virtual Channel RAM (VCR)

3.3.1 Using the VCR for Cell Storage

3.3.2 Using the VCR for Storing Channel Parameter Entries

3.3.3 Channel Groups. Combining active VCs into Logical

Groupings for Segmentation Pacing Synergy

3.3.4 Cell Multiplexing--Cell Demultiplexing. Number of ChannelsSupported by the ATMizer

3.4 The Pacing Rate Unit

3.4.1 Cell Rate Pacing (CS-PDU Segmentation Rates)

3.4.2 Global Pacing Rate

3.4.3 Channel Priority

3.5 The DMA Controller

3.5.1 DMAC Control Registers and Counters

3.5.2 Programming the DMAC

3.5.3 Using the DMA Controller to implement Cell Switching,

Segmentation and Reassembly

3.5.4 CRC32 Generation Considerations

3.5.5 Misaligned Operations Revisited

3.5.6 Using the DMA Controller to Implement Scatter and Gather

Operations

3.5.7 How to Determine when a DMA Operation has Completed

3.6 The Parallel Cell Interface

3.6.1 The Parallel Cell Interface Transmitter

3.6.1.1 Transmit Cell Sources

3.6.1.2 Queuing a Cell for Transmission

3.6.1.3 Cell Rate Decoupling

3.6.1.4 Preparing the Transmitter to Transmit

3.6.2 The Parallel Cell Interface Receiver

3.6.2.1 Received Cell Handling Options

3.6.2.2 Received Cell Indication. How the APU recognizes that

Cells are awaiting processing in the VCR

3.6.3 HEC Generation and Checking

3.6.4 External Buffering of Received Cells

3.6.5 Frequency Decoupling

3.7 The Parallel Port

4.0 The System Control Register

5.0 The ATMizer Memory Map

6.0 The ATMizer's Interrupt Structure and CpCond Hookups

7.0 Programming the ATMizer

8.0 ATMizer <-> Host Messaging

9.0 The ATMizer in Operation

9.1 Data Types Supported

9.2 The Cell Generation Process--An Overview

9.2.1 AAL1 Real-Time Data Streams

9.2.2 AAL 3/4 and 5 CS-PDU Segmentation

9.3 The CS-PDU Reassembly Process

10.0 Congestion Notification and Handling

11.0 ATMizer Signals

11.1 ATMizer Pin Diagram

11.2 ATMizer Signal List

12.0 ATMizer Interface Timing

ATMizer DETAILED DESCRIPTION

1.0 ATMizer Features

1.1 General Features

Supports ATM data rates of up to 155.54 megabits per second (mbps).

Supports simultaneous Segmentation and Reassembly of certain VCs andcell switching of others.

User programmable on-chip 32 bit MIPS RISC CPU (ATM Central ProcessingUnit--APU) controls all aspects of the ATM cell generation and switchingprocesses.

Handles contiguous and non-contiguous CS-PDUs (scatter-gather DMAoperations).

APU controls scatter-gather DMA algorithms, AAL Header and TrailerGeneration, ATM Header generation and manipulation, ATMizer--Hostmessaging, error handling, congestion control, statistics gathering,diagnostic operation and more.

Supports ATM Adaptation Layers 1, 2, 3/4 and 5, simultaneously.

Generates and appends 4 byte CRC32 field on AAL5 CS-PDU segmentation.

Generates and checks 4 byte CRC32 field on AAL5 CS-PDU reassembly.

Implements Peak Rate Pacing, Maximum Burst Length and Global Pacing foraggregate traffic shaping.

Supports up to 65,536 VCs--actual numbers are implementation specific.

On-chip elastic byte buffer and received cell buffers (2, 4, 8 or 16cells deep) eliminate the need for buffering at the ATM port. Allmetastability issues are handled by the ATMizer 50.

On-chip caching of channel parameters, buffer lists and messages in 4kilobyte Virtual Channel RAM, coupled with received cell buffers allowsfor the development of "memory-less" network interface cards thatoperate at desktop speeds (<=45 mbps). All CS-PDUs under segmentationand reassembly reside in system memory.

Operates out of system memory in low cost NIC applications, a singleunified DRAM system in high speed applications supporting a limitednumber of VCs (256) or from a combination of high speed SRAM and DRAM inhigh speed applications requiring the support of a large number of VCs(greater than 256).

Robust ATM port interface with frequency decoupling logic andmetastability logic inside of the ATMizer 50.

Powerful 32 bit DMA addressing capabilities and 32 or 64 bit DMA Datainterfacing capabilities.

General purpose eight bit Parallel Port Interface with addressing of upto 16 external devices.

Extensive diagnostic support including HEC, CRC10 and CRC32 errorforcing.

1.2 ATM Adaptation Layer Features

Controlled AAL1 Cell Generation from real-time data streams includingSAR Header generation and Residual Time Stamp Insertion.

Controlled Segmentation and Reassembly of AAL 2, 3/4 and 5 CS-PDUs.

Scatter-gather capabilities on Reassembly and Segmentation. CS-PDUs neednot be contiguous in system memory. Allows for efficient use of memoryspace, higher throughput (no moves necessary to form contiguous CS-PDUs)and low latency attributable to devices such as routers. User firmwareimplements the scatter-gather algorithm.

Higher layer header extraction and data alignment capabilities forapplication acceleration.

CRC10 generation and checking for AAL 2 and 3/4 SAR PDUs.

CRC32 generation and checking for AAL 5 CS-PDUs.

Supports simultaneous Segmentation and Reassembly of AAL 2, 3/4 and 5CS-PDUs, AAL 1 cell generation from real-time data streams and cellswitching between the ATMizer 50's ATM Receiver port and ATM Transmitterport or any memory mapped device (terminate some VCs, switch others.Implement rings, dual attach stations, switching fabrics, etc.).

1.3 ATM Layer Features

Controlled ATM Header generation and manipulation.

Cell Multiplexing/Cell Demultiplexing from up to 65,536 VCs/VPs.

On-chip caching of channel parameters in Virtual Channel Ram allows forlow cost network interface cards to be implemented without any dedicatedmemory on the card. Use the PC's/Workstation's main memory system forCS-PDU storage during S&R.

Support for VCI/VPI translation and cell switching.

Supports a user defined cell size up to 64 bytes to allow for thepre-pending of a switch specific header.

Support for multicast expansion.

On-chip Peak Rate Pacing Counters (up to 8 Peak Rates), Maximum BurstLength control.

Global Pacing Rate Register allows the APU to set the percentage of IDLEcells to be sent over the ATM port. Provides for aggregate trafficshaping and is a quick way of reducing data speeds upon congestionnotification. Gradually return to full speed operation under APUcontrol.

Advanced congestion control capabilities. User firmware specifiedcongestion control algorithms provide for immediate reaction tocongestion notification. Fast response (within one cell time) results infewer cells sent into a congested network, minimizing cell loss andCS-PDU retransmissions resulting in higher overall throughput.Congestion control routines are part of user firmware and can bemodified as more is learned about congestion in actual ATM networks.

Cell Loss Priority marking and manipulation (w/AAL 5 High-Medium-LowPriority CS-PDU support).

Automatic Cell Rate Decoupling through IDLE cell insertion.

1.4 ATM Port Physical Interface Features

Eight bit parallel transmit data output bus; PCI₋₋ -TxData(7:0).

Eight bit parallel receive data input bus; PCI₋₋ Rc-Data(7:0).

Separate transmitter and receiver sync inputs.

Eight byte deep elastic buffers in transmitter and receiver allow fordirect connection of data output and input buses to transceivers. Noexternal buffering required.

Elastic buffers driven by transceiver generated/recovered byte clocks(PCI₋₋ TxClk, PCI₋₋ RcClk). Supports any byte frequency < or=25 MHz.Clocks can be "Gapped".

All buffering and metastability issues dealt with inside the ATMizer 50.

Separate transmitter and receiver "data transfer acknowledgment" inputsignals (PCI₋₋ TxAck, PCI₋₋ RcAck) provide for Gappable operation withfree running transmitter and receiver clocks.

Allows connection to Transmission Convergence Sub-layer framing logicthat requires "gaps" in the assigned cell stream for theinsertion/extraction of framing overhead.

On-chip received cell buffers (user selectable 2, 4, 8 or 16 cells deep)adds second layer of buffering between ATM port and main memory.Buffering allows ATMizer 50 to absorb periods of high latency to mainmemory or long exception handling routines without losing receivedcells. Especially important in "memory-less" network add-in cards forPCs and Workstations where the computer's main memory is the ATMizer50's working memory space.

HEC GENERATION AND CHECKING

Cell delineation using "slip and sync on HEC error" protocol.

"Transmit Data Ready" (PCI₋₋ TxDrdy), "Beginning of Cell" (PCI₋₋ BOC),"IDLE Cell" (PCI₋₋ IDLE) and "HEC Error" (PCI₋₋ HECError) outputs to aidthe Transmission Convergence Sublayer framing logic.

1.5 Diagnostic Support Features

Unlimited user firmware controlled statistics gathering capabilities.Keep track of any statistics the application or network managementarchitecture requires.

CRC10 and CRC32 error statistics gathering.

Force HEC, CRC10 and CRC32 errors for diagnostic purposes.

ATMizer 50s are fully lock-steppable for use in fault tolerant systems.

On board APU provides for network management and troubleshooting of ATMsystem.

Download special diagnostic firmware to APU to aid system leveldiagnostics when troubleshooting system or line failures.

2.0 Operations Performed by the ATMizer 50

The ATMizer 50 is a single chip ATM network controller from LSI Logicthat, in general terms, fits into the Segmentation and Reassemblycategory of ATM control chips. In reality, the ATMizer 50 provides farmore power and flexibility than one would expect from a Segmentation andReassembly device.

The power of the ATMizer 50 comes from the inclusion within the chip ofa 32 bit, user programmable, RISC CPU based on the MIPS R3000architecture. It is user firmware downloaded to the on-chip CPU duringsystem reset that controls most of the operational aspects of theATMizer 50.

The ATMizer 50, as shipped, does not solve a particular ATM stationdesign problem. It is a group of carefully chosen hardware functionalblocks that can be woven together by user firmware in such a fashionthat the ATMizer 50 becomes tuned to solve a set of problems particularto the user's system implementation.

Segmentation and reassembly are likely to be two of the major problemssolved by the ATMizer. 50, but additional issues can be handled as wellincluding cell switching, VCI/VPI translation, statistics gathering,messaging and diagnostic operation. In addition, the way that the user'ssystem manages CS-PDU lists (i.e. lists of CS-PDUs in need ofsegmentation), memory buffers (in scatter-gather implementations),Host-ATMizer messaging and other structures can vary from system tosystem depending on the firmware architecture implemented by the user.

In general terms, the ATMizer 50 has been designed to address the ATMlayers enclosed in the box illustrated in FIG. 3.

3.0 The ATMizer 50--Functional Blocks

The ATMizer 50 is fabricated as a single integrated circuit chip on asubstrate 66 as illustrated in FIG. 2. As stated previously, theobjective in designing the ATMizer 50 was to provide ATM systemdesigners with a Segmentation and Reassembly chip that can, through userfirmware control, be used to implement ATM end stations and switchingstations in a number of very divergent fashions. As such the ATMizer 50is a device that provides a number of critical hardware functions thatare "brought to life" by the firmware that a user downloads to theATMizer 50's APU at system reset time.

The responsibilities attributed to the ATMizer 50 in a system are afunction of this firmware. Therefore, it is important for the systemdesigner to understand the functional blocks of the ATMizer 50 prior toundertaking any system architectural activities.

The ATMizer 50 consists of the following seven functional blocks asillustrated in FIG. 4.

1. ATMizer Processing Unit (APU) 52. The "brain" of the ATMizer 50 isthe on board 32 bit MIPS RISC based CPU that controls all aspects ofATMizer 50 operation. This specification refers to the on-board CPU asthe APU 52. The APU 52 must process every incoming cell and generateevery outgoing cell. It is the APU 52 that provides the level ofoperational control that is necessary to support such functions asinterleaved circuit termination (S&R) and cell switching of multiple ATMAdaptation Layer type cells, scatter-gather memory managementoperations, intelligent congestion control algorithms, trafficstatistics gathering and robust ATMizer <-> Host messaging.

2. Instruction RAM (IRAM) 54. The APU 52 runs the user supplied firmwareroutine from an on-board 1024×32 single cycle SRAM which constitutes theIRAM 54. The SRAM is loaded at system reset and the code then remainsstatic in the SRAM throughout system operation. However, if systemfailures occur, the diagnostic operating system may chose to download adiagnostic control routine to the IRAM 54 so that the APU 52 canactively participate in the troubleshooting process.

3. Virtual Circuit RAM (VCR) 56. The VCR 56 is the most configurableaspect of the ATMizer 50. While the VCR 56 is simply a 1024×24 twoRead/Write port SRAM, the software partitioning of this SRAM will varydramatically from user to user and application to application. Tradeoffsin VCR configuration will impact issues such as the number of channelssupported and the size, structure and speed of the external main memorysystem.

All cells received from the ATM port side are written into the VCR 56 toawait either reassembly or switching operations initiated by the APU 52.AAL 1, 2, 3/4 and 5 cells are "built" in the VCR 56 by a combination ofDMA operations and APU operations before being passed to the ATMtransmitter.

The VCR 56 may also be used to store Channel Parameter Entries,available buffer lists and other data structures required for systemoperation. In some applications, all Channel Parameters Entries will bestored in the VCR 56 while in other applications Channel ParameterEntries will be stored in main memory (combination systems are alsolikely).

4. Pacing Rate Unit (PRU) 58. The PRU 58 contains eight Peak Rate PacingCounters (PRPC) 58a that are used to control the rate of CS-PDUsegmentation. Whenever one or more PRPCs 58a times out, the PRU 58asserts the APU's CpCond2 input allowing the APU 52 to poll for thistime out condition. If the APU 52 finds CpCond2 set, it branches to theSegmentation routine.

The PRU 58 also contains the Channel Group Credit Register (CGCR) 58b,an eight bit, APU readable/writable register containing one bit for eachPRPC 58a. A PRPC 58a that has timed out but has not yet been serviced bythe APU 52 has its bit set in the CGCR 58b. Firmware running on the APU52 can implement channel priority by selectively servicing ChannelGroups that have timed-out. Four of the eight 12 bit PRPCs 58a can beconfigured into two general purpose 24 bit timer/counters for generalpurpose usage. These timer/counters provide a robust set of featuresincluding APU interrupt on time-out capabilities.

The PRU 58 further includes a Global Rate Pacing Register (GRPR) 58cwhich will be described in detail below.

5. DMA Controller (DMAC) 60. The DMA controller 60 is a slave resource(as seen by the APU 52) utilized by the APU 52 to accomplish datatransfers between the on-chip VCR 56 and memory mapped devices. Whilethe APU 52 is the "brains" behind DMA operations, the DMA controller 60is the "muscle" behind such operations. Because the APU 52 initializesthe DMA controller 60 at the beginning of each operation, the DMAcontroller 60 effectively supports an unlimited number of channels.

The DMA Controller 60 is extremely powerful, supporting everycombination of local and memory byte alignments on transfers. Thispowerful support of aligned and misaligned operations gives the ATMizer50 an ability to participate in robust Scat-ter-Gather operations. TheDMA controller 60 is also responsible for generating CRC32 results forAAL 5 SAR CS-PDUs. The DMA Controller 60 operates in 32 bit address and32 bit data transfer mode.

6. Parallel Cell Interface (PCI) 62. The PCI 62 is the ATMizer 50'sinterface to the ATM port side circuitry, and includes a PCI Transmitter62a and a PCI Receiver 62b. The PCI 62 is 8 bits wide in both thetransmit and receive directions and connects directly to the actualTransmission Convergence Sublayer framing circuitry. In the receivedirection, the PCI 62 is responsible for reconstructing ATM cells in theVCR 56 from data received from the external framing logic. In thetransmit direction, the PCI 62 is responsible for transferring cellsfrom the VCR 56 to the external framing logic.

The PCI 62 also contains data buffers and frequency decoupling logic toallow for a direct connection between the ATMizer 50's ATM ports and theATM line transceivers. All metastability issues are addressed and solvedby the ATMizer 50.

7. Parallel Port 64. The Parallel Port 64 is an eight bit port that canbe accessed by the APU 52 directly through Load and Store commands. TheParallel Port 64 may be used to pass information between the ATMizer 50and the system controller, between two or more ATMizers or as part ofthe ATMizer <-> Host messaging system. The Parallel Port 64 can also beused to access external devices while the DMA controller 60 is busy andto pass information to an external device about an active DMA operation.

3.0 ATMizer FUNCTIONAL BLOCKS

3.1 ATMizer Processing Unit (APU) 52

The APU 52 is a 32 bit RISC CPU based on the MIPS R3000 architecture. Itis the inclusion of this powerful, user programmable CPU that gives theATMizer 50 its unique capabilities. APU firmware is responsible for arange of functions from cell building (SAR Header and Trailergeneration, ATM Header retrieval from the Channel Parameter Entry forthe VC, ATM Header manipulation and insertion, and DMA operationinitialization for SAR SDU retrieval) to ATMizer <-> Host messaging andchannel servicing sequencing.

The system designer is responsible for writing the firmware that will beexecuted by the APU 52. Firmware is downloaded to the ATMizer 50 atsystem reset and controls almost all operational functions of theATMizer 50 including the following functions:

SAR PDU GENERATION, ATM CELL GENERATION

The APU 52 is responsible for generating SAR Headers (AAL 1, 2 and 3/4)and Trailers (AAL 2 and 3/4) during segmentation and reassembly (theCRC10 field is automatically generated and inserted by the PCI 62). SARHeader generation includes sequence number generation and checking aswell as message type insertion and extraction (BOM, COM, EOM, SSM).

The APU 52 is also responsible for initiating the appropriate DMAoperations to accomplish SAR SDU retrieval from memory based real timedata buffers (AAL 1) or CS-PDUs. The APU 52 is also responsible for ATMHeader retrieval and manipulation, including PTI and CLP fieldmodification. For cells that are to be switched, the APU 52 isresponsible for making the initial switching decision based oninformation contained in the Channel Parameter Entry for the VC as wellas for accomplishing VCI/VPI translation if such an operation isspecified in the Channel Parameter Entry.

DMA OPERATION INITIALIZATION

To initiate a DMA operation the APU 52 sets the main memory startaddress (byte offset), the local address and local byte offset, thenumber of bytes to be transferred and the transfer direction (Rd vs. Wr)in the DMA Engine. Once these parameters have been written into the DMAengine, the DMA controller operates autonomously to accomplish theentire transfer.

The APU 52 initiates DMA operations to retrieve SAR SDUs duringsegmentation operations, to restore SAR SDUs to their respective CS-PDUsduring reassembly operation, to switch entire cells, headers andtrailers intact, to other memory mapped ATM ports during switchingoperations, to retrieve and restore Channel Parameter Entries inapplications utilizing off chip SRAM to support an extended number ofVCs or to retrieve a Channel Parameter Entry to be appended to the endof a VCR based Channel Group in applications supporting on-chip cachingof Channel Parameter Entries in the VCR 56, and to transfer SAR SDUs toand from real time data stream buffers in applications supporting AAL1circuit interfaces (such as T1 lines).

PACING RATE UNIT CONFIGURATION

The APU 52 has write access to the eight Peak Rate Pacing Counters 58aand their initialization registers (not shown). The APU 52 sets theinitial count values by writing a 12 bit value into one of the eightPeak Rate Pacing Registers. The APU 52 can also read the Channel GroupCredit Register 58b to determine which PRPCs 58a have expired.

The Pacing Rate Unit 58 informs the APU 52 that a PRPC 58a has timed-outby asserting the APU 52's CpCond2 input. The APU 52 polls this conditionby periodically executing the "Branch on CpCond2 True" instruction. Ifthe APU 52 evaluates this condition as True it branches to theSegmentation routine and begins segmenting the CS-PDUs specified in theindividual Channel Parameter Entries for the Channel Group whose PRPC58a has timed-out (forcing the assertion of CpCond2).

The APU 52 will generate a number of cells per CS-PDU/Channel ParameterEntry, as indicated in the Channel Parameter Entry, prior to proceedingto the next Channel Parameter Entry in the Channel Group. The APU 52implements channel priority by being selective (and creative) in theorder in which it handles segmentation when multiple PRPCs have timedout simultaneously and are awaiting service.

In between cell generation procedures the APU 52 will check for receivedcells, and must interleave the generation of cells with the reception(termination or switching) of cells as well as with any ATMizer <-> Hostmessaging actions that may be required.

PARALLEL CELL INTERFACE CELL QUEUING AND CELL PROCESSING

The APU 52 is responsible for queuing cells for transmission by writingthe VCR 56 start address of a cell into the Cell Address FIFO in the PCITransmitter 62a. If no cell address is present in the FIFO when an endof cell boundary is reached, the Transmitter 62a will automatically sendan IDLE cell.

For received cells, the APU 52 is responsible for deciding between cellswitching and circuit termination on a per VC basis. The APU 52accomplishes internal cell switching (cell switching between itsReceiver and Transmitter) by passing the VCR 56 addresses of a receivedcell targeted for internal switching to the Cell Address FIFO in theTransmitter. A cell targeted for external switching (switching overDMA₋₋ Data(31:0)) has its VCR 56 addresses passed to the DMA Controller60.

The APU 52 also is responsible for setting the Global Pacing RateRegister 58c in order to shape the assigned cell content of the outgoingcell stream. For cells that are to be terminated (i.e. reassembled intoCS-PDUs) the APU 52 retrieves the Channel Parameter Entry for the VCover which the cell arrived to obtain information required to reassemblethe SAR SDU into its corresponding CS-PDU.

This information includes the memory address of the tail end of theCS-PDU under reconstruction. The APU 52 then initiates a DMA operationto transfer the SAR SDU from the VCR 56 to memory by passing the DMACthe local (VCR 56) address of the SAR SDU, the memory address of theCS-PDU and the number of bytes of SAR SDU to be transferred. The DMAController 60 then executes the transfer, leaving the APU 52 free to doother things.

MEMORY ALLOCATION

During the reassembly process the APU 52 is responsible for memorybuffer management. If memory is to be allocated to incoming CS-PDUs in"fragments", the ATMizer 50's APU 52 is responsible for trackingfragment boundaries, issuing additional fragments to CS-PDUs as needed,generating link lists of the fragments allocated to a given CS-PDU andATMizer <-> Host messaging to inform the host of CS-PDU completesituations, error and congestion problems.

In the transmit direction, the APU 52 is responsible for recognizing anddealing with the difference between end-of-fragment boundaries andend-of-CS-PDU boundaries.

ATMizer <-> HOST MESSAGING

The ATMizer 50 does not enforce a particular messaging system betweenthe on-chip APU 52 and the host system. The user implements his ownmessaging system by polling the ATMizer 50₋₋ Int input (connecteddirectly to CpCond0 and tested with the "Branch on CpCond0 True"instruction) for an indication that the host wishes to communicate withthe ATMizer 50 and by setting the ATMizer 50's Host₋₋ Int output toindicate to the host that the ATMizer 50 wishes to or has already passeda message to the host system.

The APU 52 can also read and/or write any DMA memory mapped or ParallelPort memory mapped location as part of a messaging mailbox system. GP₋₋Int1 or GP₋₋ Int2 could also be used in addition to or in place ofATMizer 50₋₋ Int as part of the messaging system.

CONGESTION CONTROL

As stated previously, the ATMizer 50 is capable of executing orfacilitating almost any congestion control algorithm. The APU 52 looksat the appropriate ATM Header field/s of each incoming cell fornotification of congestion. If congestion notification is found toexist, the APU 52 can take immediate action. Such actions may includeone or more of the following:

1. Notify the Host that congestion has been seen utilizing the ATMizer<-> Host messaging scheme developed by the user.

2. Lower one or more Peak Rate Pacing Counter initialization values.

3. Reduce the overall assigned cell throughput rate by setting a"lesser" value in the Global Pacing Rate Register.

4. Set the CLP fields of outgoing cells to 0 in lieu of lowering theoverall information rate.

3.2 1024×32 Instruction RAM (IRAM 54)

The 1024×32 Instruction RAM 54 contains the 4096 bytes of user written"firmware" that power the APU 52. The IRAM 54 code is downloaded duringsystem reset (Resetx asserted) through a series of memory writeoperations executed by the host processor with the ATMizer 50 serving asthe target device. The ATMizer 50 acts as a slave device for the purposeof this download process.

The host accomplishes the data transfer to the ATMizer 50 by issuing1024 (or less) write operations to 1024 (or less) consecutive memoryaddresses. These memory address have common MSBs that result in externallogic selecting the ATMizer 50 as the targeted resource of the writeoperations.

As a result of each write operation, external logic asserts the ATMizer50's DMA₋₋ RdWrAck input. The ATMizer 50 responds to the assertion ofDMA₋₋ RdWrAck while Resetx is low by writing the data sourced by thehost on DMA₁₃ -Data(31:0) into the on-board IRAM 54 on the rising edgeof clock. The ATMizer 50 generates the IRAM 54 index (i.e. the IRAM 54write address) internally, starting at location zero and incrementingthe address by one word each time DMA₋₋ RdWrAck is asserted.

Therefore, it is imperative that the IRAM 54 code be writtenconsecutively until the entire firmware routine has been written intothe IRAM 54. Once the entire user firmware routine has been written intothe on-chip IRAM 54, the system can release the ATMizer 50's Resetxinput and the APU 52 will begin firmware execution at the R3000 resetvector. DMA₋₋ DataOEx and DMA₋₋ AdrOEx should be deasserted during slavewrite operations.

The ATMizer 50 will generate consecutive DMA memory addresses to IRAM 54code downloading, beginning at memory address zero and incrementing byone word each time DMA₋₋ RdWrAck is asserted. If external logic wishesto use the address sourcing capability of the DMA to boot from a ROM orsome other device, it should assert DMA₋₋ AdrOEx during the ATMizer 50initialization processor. If external logic relies on programmed I/O toconfigure the IRAM 54, DMA₋₋ AdrOEx should most likely be deasserted toinsure that the ATMizer 50 does not drive the DMA₋₋ Address(31:2) bus.

3.3 Virtual Channel RAM (VCR 56)

The Virtual Channel RAM 56 is a 1024 word×32 dual ported RAM thatprovides the ATMizer 50 with many of its unique capabilities. The VCR 56should be thought of as the central resource within the ATMizer 50.Almost all ATMizer 50 operations revolve around the transfer of data toand from the VCR 56. The VCR 56 can be read and written by the DMAcontroller 60, the Parallel Cell Interface 62 and the APU 52.

All incoming cells (cells arriving over the Receiver in the ParallelCell Interface) are written into the VCR 56 prior to processing (the APU52 will decide how to process a cell. It can chose to terminate a cell(reassemble it into a CS-PDU or a data buffer) or to switch a cell(internally or externally). All outgoing cells are either constructed inthe VCR 56 (segmentation) or transferred to the VCR 56 (externalswitching) prior to transmission. In addition, Channel ParameterEntries, memory buffer lists, messages and other parameters can all bestored within the VCR 56.

It is this ability to store such parameters inside the ATMizer 50 thatallows the ATMizer 50 to be used in a variety,of cost sensitiveapplications such as memory-less network interface cards supporting alimited number of simultaneously active VCs.

Two sample VCR 56 constructions are illustrated in FIGS. 5a and 5b. Inthe first example, of FIG. 5a, a Network Interface Card (NIC) for a PCor Workstation supporting a limited number of open channels, all ChannelParameter Entries for both transmit and receive channels are stored inthe VCR 56 eliminating the need for off chip local memory. In the secondexample of FIG. 5b, a router supports an unlimited number of openchannels but places a restriction on the number of VCs that can haveCS-PDUs under active segmentation at any one time.

In the sample system we have limited to 256 the number of transmitchannels that can be "active" simultaneously and we cache all ChannelParameter Entries for these active channels in the VCR 56.

A 155 mbps ATM pipe evenly split amongst 256 channels yieldsapproximately 605 kilobytes/sec per channel. In this scenario we havenot limited the number of open transmit channels, only the number ofchannels that can have CS-PDUs undergoing segmentation simultaneously.

Once one CS-PDU has been completely segmented the APU 52 can swap outits Channel Parameter Entry for the next in line. Channel ParameterEntries for channels that are active in the receive direction are storedoff-chip in local memory. This allows the router to support an unlimitednumber of simultaneously active receive channels.

Without an intelligent memory fragment allocation plan, support for alarge number of VCs would swamp most memory systems. Fortunately theATMizer 50 combines support for external Channel Parameter Entries witha capability to do link list based CS-PDU scattering during reassembly(allocate memory in small "fragments" as needed). The net result is thatthe sample router is able to support an unlimited number of opentransmit and receive channels from a single unified DRAM based memorysystem with a single restriction on the number of transmit channels thatcan be actively undergoing segmentation at one time.

In high end applications, it is possible to support an unlimited numberof simultaneously active transmit and receive channels by storing allChannel Parameter Entries off chip. This puts certain demands on thespeed of local memory that may force the usage of SRAM for ChannelParameter Entry storage.

3.3.1 Using the VCR 56 for Cell Storage

INCOMING CELLS

The Receiver in the ATMizer 50's Parallel Cell Interface reconstructscells received from the external transmission convergence framing logicin the VCR 56. The PCI 62 allocates 64 bytes of VCR 56 memory to eachincoming cell. The actual size of a cell is user selectable (up to 64bytes) and must be programmed in the System Control Register as part ofthe APU 52's system initialization routine.

The Receiver reconstructs cells beginning at VCR address 0000. The first128 bytes (2 cells), 256 bytes (4 cells), 512 bytes (8 cells) or 1024bytes (16 cells) of the VCR 56 are set aside for Received Cell Holders.Cells are written into the VCR 56 in a modulo 2, 4, 8 or modulo 16fashion. Therefore, it is important that cells be processed before theyare overwritten.

Cell buffering in the VCR 56 helps to decouple the incoming cell streamfrom memory interface latency and is especially helpful in situationswhere the APU 52 is temporarily unable to process incoming cells due toexecution of an extended routine.

Cells written into the VCR 56 are processed in the order of theirarrival by the APU 52 and are either:

1. Switched over the internal Transmitter;

2. Switched over the main memory interface; or

3. Reassembled into memory based real time data stream buffers orCS-PDUs. The decision to switch or terminate a cell is made by the APU52 after examining the information stored in the Channel Parameter Entryfor the VC over which the cell arrived.

OUTGOING CELLS

All cells must be either moved to (external switching) or constructed in(segmentation) the VCR 56 prior to transmission. Software can set asidean area in the VCR 56 to act as the staging area for cell switching andgeneration (shown in FIG. 3.3 as the Transmit Cell Builder regions).Outgoing cells are transferred from the VCR 56 to the externaltransmission convergence framing logic by the Transmitter in the PCI 62.The Transmitter works off of VCR 56 memory pointers.

Whenever the APU 52 wishes to have a VCR 56 resident cell transferred tothe transmission convergence framing logic, it simply writes a VCR 56pointer to the cell into the Transmitter's Cell Address FIFO. Thetransmitter then handles the transfer automatically.

A benefit to this pointer method is that it enforces no restrictions onthe internal location of cells slated for transmission accept that theybe VCR 56 resident. As a result, the ATMizer 50 can switch Received CellHolder resident cells out over the Transmitter by simply passing apointer to the cell to the Cell Address FIFO (internal switching).

To switch a cell from an external device (i.e. to source a pre-existingmemory based cell out over the ATMizer 50's PCI Transmitter 62a) the APU52 must first initiate a DMA operation to bring the cell into the VCR 56from some temporary memory buffer. Once in the ATMizer 50, the APU 52passes the VCR 56 pointer for the cell to the Cell Address FIFO in thesame fashion as for internal switching. Segmentation requires ATM andSAR (AAL 1, 2 and 3/4) Headers and Trailers (AAL 2 and 3/4) to beappended to the SAR SDUs by the APU 52. But once a cell is constructedin the VCR 56 the APU 52 again passes a pointer to the cell to the CellAddress FIFO and the Transmitter sends the cell to the transmissionconvergence framing logic, one byte at a time.

3.3.2 Using the VCR 56 for storing Channel Parameter Entries

Beyond transmit and received cell holding, how the VCR 56 is used willvary dramatically from application to application. For the APU 52 togenerate a cell it must know certain information about the virtualcircuit over which the cell will pass and information about the CS-PDUfrom which the cell will be generated. Such information includes:

1. The main memory address of the CS-PDU or real time data buffer fromwhich the SAR SDU will be retrieved.

2. The number of bytes remaining in the CS-PDU or CS-PDU fragment (inscatter-gather applications).

3. In scatter-gather applications, whether or not the current CS-PDUfragment is the last fragment of a multi-fragment CS-PDU.

4. The base ATM Header that is to be appended to each cell.

5. The ATM Adaptation Layer type that is to be used to segment orreassemble cells originating or terminating on the given VC.

6. The previous SAR Header/Sequence Number (for AAL 1, 2 and AAL 3/4circuits).

7. The CRC32 partial result for the CS-PDU (for AAL 5 circuits).

Collectively, these parameters provide the APU 52 with all of theinformation that is needed to process an incoming cell or to segment aCS-PDU into a stream of cells. In this specification we refer to a RAMbased data structure that contains all of the pertinent informationabout a single VC as a Channel Parameter Entry for the VC.

The ATMizer 50 is unique in that it does not enforce any ChannelParameter Entry data structure. User firmware will dictate the actualChannel Parameter Entry data structure, how VCs are grouped together andhow the segmentation process will be conducted on a grouping. The systemdesigner creates the Channel Parameter Entry data structure architectureto fit his system and then writes the APU 52 firmware to work withinthis environment. For example, a system that supports AAL5 CS-PDUsegmentation and reassembly will require less information in a ChannelParameter Entry than a system that supports AAL5 CS-PDU segmentation andreassembly and cell switching. Furthermore, a system that supportssimultaneous segmentation and reassembly of AAL 1, 2, 3/4 and 5 CS-PDUswill require an even more robust Channel Parameter Entry for each VC.

Example Channel Parameter Entries for the first two systems follow.

A SYSTEM SUPPORTING AAL 5 SEGMENTATION AND REASSEMBLY ONLY

Channel Parameter Entry for CS-PDU/VC Undergoing Segmentation

1. CS-PDU Current Main Memory Address (2 to 4 bytes, depending on thesize of main memory).

2. Base ATM Header to be appended to each cell (4 bytes, APU 52 handlesPTI and CLP manipulation).

3. CRC32 Partial Result (4 bytes).

4. DMA Current Byte Count (1-2 bytes, how many bytes left in the CS-PDUor CS-PDU fragment).

5. Control (CS-PDU priority, segmentation burst length, last fragmentflag, etc.).

Channel Parameter Entry for CS-PDU/VC Undergoing Reassembly

1. CS-PDU Current Main Memory Address (2 to 4 bytes, depending on thesize of main memory).

2. CRC32 Partial Result (4 bytes).

3. DMA Current Byte Count (1-2 bytes, # of bytes left in current memorybuffer).

A SYSTEM SUPPORTING AAL 5 SEGMENTATION AND REASSEMBLY AND CELL SWITCHING

Channel Parameter Entry for CS-PDU/VC undergoing segmentation

1. CS-PDU Current Main Memory Address (2 to 4 bytes, depending on thesize of main memory).

2. Base ATM Header to be appended to each cell (4 bytes, APU 52 handlesPTI and CLP manipulation).

3. CRC32 Partial Result (4 bytes).

4. DMA Current Byte Count (1-2 bytes, how many bytes left in the CS-PDUor CS-PDU fragment).

5. Control (CS-PDU priority, segmentation burst length, last fragmentflag, etc.).

Channel Parameter Entry for CS-PDU/VC Undergoing Reassembly

1. CS-PDU Current Main Memory Address (2 to 4 bytes, depending on thesize of main memory).

2. CRC32 Partial Result (4 bytes).

3. DMA Current Byte Count (1-2 bytes, # of bytes left in current memorybuffer).

4. Control (Switch or Terminate; if switch: VPI/VCI Translation?, Localor Main Memory Switch?).

Channel Parameter Entry for CS-PDU/VC Undergoing Cell Switching

1. New VCI and/or New VPI.

2. Control (Switch or Terminate; if switch: VPI/VCI Translation?, Localor Main Memory Switch?).

It is important to understand that both the concept of Channel ParameterEntries as well as the structure and location of such entries are alluser definable structures. The same is true for Channel Groups asdescribed below. A distinction must be made between the hardwarefeatures that are provided by the ATMizer 50 and the means of employingthose features to get a particular job done that are provided by userfirmware.

3.3.3 Channel Groups. Combining active VCs into Logical Groupings forSegmentation Pacing Synergy

This specification introduces the concept of a "Channel Group". AChannel Group is simply a group of VCs whose "Channel Parameter Entries"form a contiguous list, either in the VCR 56 (on-chip memory) or in mainmemory. The VCs that form a Channel Group reach their segmentationservice intervals simultaneously (i.e. they are driven by a common PeakRate Pacing Counter (PRPC 58a)).

Once a Peak Rate Pacing Counter 58a times out, firmware running on theAPU 52 will proceed to sequence through the list of VCs/CS-PDUs (i.e.the Channel Group), generating a specified number of cells from eachCS-PDU before proceeding on to the next entry in the Channel Group.CS-PDU before proceeding to the next Channel Group entry (and therefore,the next CS-PDU) is controlled by user firmware.

FIG. 6 illustrates sample VCR 56 software structures for cell holdingand on-chip channel support for segmentation, whereas FIG. 7 illustratesa sample channel parameter entry structure for receive channels. In FIG.6, the AAL 5 channel parameter entry for a VC within a CS-PDU undergoingreassembly saves RAM space by limiting the address field size and bytracking the number of 48 byte blocks left in the CS-PDU fragmentinstead of the number of bytes.

In the example system, a Channel Parameter Entry for a VC over which weare segmenting and transmitting a CS-PDU requires 16 bytes ofinformation. These 16 bytes include 4 bytes for storing the memoryaddress (where we left off) of the CS-PDU under segmentation on the VC,4 bytes for storing the ATM header to be appended to each SAR-PDU (theAPU 52 will modify the PTI and CLP fields as necessary), 4 bytes forCRC32 partial storage (if we are using AAL 5 on this VC), 2 bytes forthe CS-PDU byte count (or CS-PDU fragment current byte count inscatter-gather applications) and 2 bytes for control information such asburst length (how many cells do we generate before proceeding to thenext Channel Group entry), CS-PDU priority (High-Medium-Low) for AAL 5VCs or the previous SAR header for AAL 1, 2 or 3/4 VCs as well as anyother user defined constructs.

This is simply a user defined data-structure and not a structureenforced by the ATMizer 50). The host system manages CS-PDU sequencingover a single VC through either a linked list mechanism (parsing drivenby the ATMizer 50) or through an explicit messaging mechanism wherebythe host waits for a "CS-PDU Segmentation Complete" message from theATMizer 50 before "passing" a new CS-PDU to the ATMizer 50 to besegmented and transmitted over a given VC (passing implies passing a newChannel Parameter Entry to the ATMizer 50 with an indication of whichChannel Group/PRPC the Channel Parameter Entry should be appended to.

The ATMizer 50 appends the new entry to the specified Channel Group).The Host uses memory mailboxes and Host <-> ATMizer 50 messaging to"pass" a new Channel Parameter Entry to the ATMizer 50. ChannelParameter Entries for channels carrying CS-PDUs undergoing reassemblycan be built more compactly than for channels carrying CS-PDUsundergoing segmentation.

In the sample VCR 56 (or it could be main memory based in applicationssupporting a large number of simultaneously active receive VCs)construction illustrated in FIGS. 5 and 6, the APU 52 uses the VCIcontained in the ATM Header of an incoming cell as an index into a tablethat is either VCR 56 based (limited number of simultaneously activereceive channels) or main memory based (unlimited number ofsimultaneously active receive channels) to retrieve the ChannelParameter Entry for the VC.

In this fashion, Channel Parameter Entries for receiver orientedchannels are listed in order of their VCIs. No such restriction appliesin our sample system for the transmit direction where a grouping andparsing mechanism is employed.

3.3.4 Cell Multiplexing--Cell Demultiplexing. Number of ChannelsSupported by the ATMizer 50

The ATMizer 50 can handle up to 65,536 VCs simultaneously, performingcell multiplexing and pacing for all of the active channels. However,there are tradeoffs to be made between the number of channels supported,the data rate of the ATM port and the cost and structure of the memorysystem deployed.

For example, in a network interface card operating at desktop speeds(<=45 mbps) it is possible to limit the number of VCs supported to 256(128 Tx and 128 Rc). In such a scenario, the on-chip Virtual Channel Ram56 can be used to cache all the relative parameters for each of thesechannels. As a result, the ATMizer 50 need only access main memory toretrieve and retire SAR-SDUs and host memory can be used for CS-PDUstorage. In such a scenario, the NIC itself need not contain any memory.

In applications requiring the support of a very large number ofchannels, the on chip VCR 56 can not hold all of the needed channelinformation. As a result, it may be necessary to provide high speedSRAM, accessible by the ATMizer 50's DMA Engine, for channel parameterstorage. This gives the ATMizer 50 fast access to the information neededfor segmenting and reassembling CS-PDUs and for the switching of cells.CS-PDU storage would likely be handled in a local memory system, DRAM orSRAM based.

Scenarios exist that are essentially a cross between the two exampleslisted above. In certain systems it is possible to limit the number ofsimultaneously active Transmit channels. In this scenario there is nolimit on the number of Tx VCIs supported, only in the number that canhave CS-PDUs under segmentation at any one point in time. If the numberis limited to 128, then all Tx channel parameters can be cached on chip.The time savings associated with caching Tx parameters in the VCR 56yields added time to retrieve the parameters needed for reassembly.

This added time may allow the use of a single interleaved DRAM systemfor both CS-PDU and Channel Parameter storage. It is important to notethat the number of TX VCIs has not been limited in this example, onlythe number of Tx VCIs that can have CS-PDUs under active segmentation bythe ATMizer 50 at any one time. An unlimited number of TX VCIs can besupported by "swapping out" a Channel Parameter Entry/VC/CS-PDU for anew Channel Parameter Entry/VC/CS-PDU once its CS-PDU (or CS-PDUfragment) has been segmented. The inclusion of SRAM on the ATMizer 50opens a wide range of possibilities for system implementations.

3.4 Pacing Rate Unit (PRU) 58

CELL RATE PACING (CS-PDU SEGMENTATION RATES), GLOBAL PACING AND CHANNELPRIORITY

The Peak Rate Pacing Counters 58a and the Channel Group Credit Register58b are illustrated in FIG. 8.

3.4.1 Cell Rate Pacing (CS-PDU Segmentation Rates)

AVERAGE RATE

The ATMizer 50 contains all of the features necessary for implementingthe ATM layer Peak Rate Pacing and Maximum Burst Length controlfunctions. Average Pacing is not expected to be implemented by theATMizer 50 although it could be. Average pacing is expected to beimplemented by the host processor which will have access to areal-time-clock.

To maintain the Average Pacing Rate agreed to at connectionestablishment, the host processor keeps a running total of the number ofbytes sent over each established VC. Prior to queuing a new CS-PDU forsegmentation over a given VC, the host processor must first determine ifqueuing the CS-PDU would violate the Average Rate for the VC.

To do this the processor calculates the amount of time that has passedsince the last checkpoint. It then divides the total number of bytessent out over the VC since the last checkpoint by the elapsed time. Theresult is the actual "Average Pacing Rate" in bytes/second.

If queuing the next CS-PDU would result in a violation of the agreed toAverage Pacing Rate for the Virtual Circuit then the host processor willwait a period of time before passing the CS-PDU to the ATMizer 50 forsegmentation.

If queuing the CS-PDU would not violate the Average Pacing Rateparameter, the CS-PDU is "passed" to the ATMizer 50 for segmentation. Asstatistical multiplexing issues become better understood software can bemodified to implement Average Rate Pacing in the most ATM networkfriendly fashion.

PEAK RATE PACING AND BURST LENGTH

Once a CS-PDU or CS-PDU fragment has been "passed" to the ATMizer 50 forsegmentation, the ATMizer 50 controls the rate of cell generation fromthe CS-PDU and the number of back-to-back cells generated from a CS-PDUeach time the ATMizer 50 segments a portion of it.

There are eight user programmable "Peak Rate Pacing Counters" (PRPC 58a)in the ATMizer 50, and a CS-PDU can be "attached" to any one of theeight. A Peak Rate Pacing Counter 58a is simply a 12 bit down counterthat automatically reloads to an APU 52 specified value upon reachingzero. Each PRPC 58a counts down by one on each system clock tick (Clk).External logic can temporarily or periodically suspend the down countingof the PRPC 58as by asserting the ATMizer 50's PRU₋₋ CountDisable input(providing that the PRPC 58a has been configured to be sensitive toPRU₋₋ CountDisable).

Since each CS-PDU attached to a given PRPC 58a may have its own "BurstLength" value, the count in the Peak Rate Pacing Register actuallydetermines the "Service Interval" for the channel group and notnecessarily the peak rate of cell generation for CS-PDUs attached tothat PRPC 58a (note: CS-PDUs attached to a particular PRPC 58a withsimilar characteristics such as channel priority are collectivelyreferred to as a "Channel Group".

More than one Channel Group can be attached to a single PRPC 58a). Ofcourse, if the burst lengths for each CS-PDU attached to a PRPC 58a areidentical, the PRPC 58a count will determine the actual peak rate ofsegmentation for CS-PDUs belonging to that Channel Group.

CS-PDUs are attached to a PRPC 58a by the host processor. When the hostpasses a "Segment CS-PDU" information packet to the ATMizer 50, itincludes in the information packet an indication of which PRPC 58ashould be used to define the Service Interval for segmenting the CS-PDU.It also includes the Burst Length value for the CS-PDU (i.e. how manycells should be generated and sent, back-to-back, for the CS-PDU at eachservice interval). The ATMizer 50, upon receiving this "Segment CS-PDU"information packet (through Host-ATMizer Messaging), appends the channelparameters for the CS-PDU to the end of the specified channel group andbegins the segmentation process on the CS-PDU the next time itsassociated PRPC 58a times-out.

When a PRPC 58a reaches zero, all CS-PDUs associated with that PRPC 58aare essentially given "Credit to Send". Anytime one or more Peak RatePacing Counters 58a have timed out but have not yet been serviced (i.e.the APU 52 has yet to clear its bit in the Channel Group Credit Register58b), internal hardware asserts the APU 52 input CpCond2.

Firmware running on the APU 52 periodically checks the state of CpCond2by executing the "Branch on Coprocessor Condition 2 True" instruction.If CpCond2 is True, one or more Peak Rate Pacing Counters 58a havetimed-out and the APU 52 must segment the CS-PDUs attached to the PRPC58a or PRPC 58as that have reached their service intervals. The APU 52can determine which PRPC 58a has timed-out by reading the 8 bit ChannelGroup Credit Register (CGCR) 58b. Each bit set in the CGCR 58b indicatesthat the corresponding PRPC 58a has timed out since its bit was lastcleared by the APU 52. APU 52 firmware clears the appropriate bit whenit has serviced all channels in a particular channel group.

When servicing a channel group, APU firmware can choose to generate andsend one or more cells for a VC before servicing the next VC in thechannel group. The number of cells to be sent before proceeding to thenext channel group entry can be defined either by construction (i.e. thesame for each member of a channel group and embedded into the firmwaredirectly) or by a field inside the Channel Parameter Entry for the VC.Firmware running on the ATMizer 50 segments the number of cellsspecified by this Burst Length value before proceeding to the nextchannel group entry.

A side effect of this process is that the amount of time required toaccess and restore a Channel Parameter Entry can be amortized overseveral cells, effectively reducing the number of APU instructions andthe amount of time required to generate a cell. This may be ofimportance in high speed applications (155 mbps) supporting a largenumber of VCs (>512).

GENERAL FACTS ABOUT THE PRU--PRPC CONTROL

Each PRPC 58a in the PRU 58 has a 14 bit initialization registerassociated with it. The APU 52 writes an initialization word into theinitialization register using a store word or store half wordinstruction. Bits eleven through zero of the APU 52's data bus arewritten into the targeted initialization register as the initializationcount. Bits twelve and thirteen are also saved but are used as controlbits and are not part of the 12 bit down count initialization value.

Bit 12 controls sensitivity to the external PRU₋₋ CountDisable signal.If bit 12 is set for a given PRPC 58a, its count will be suspendedwhenever external logic asserts PRU₋₋ CountDisable. If bit 12 is not setfor a given PRPC 58a, its count will not be suspended whenever externallogic asserts PRU₋₋ CountDisable. In this fashion, implementations arepossible that have certain PRPCs sensitive to the external count disablefunction while other PRPC 58as are not sensitive to this externalsignal.

Bit 13 controls whether the PRPC 58a is enabled or not. If a PRPC 58a isnot being used it should not be allowed to accumulate credit and causespurious assertions of the APU 52's CpCond2 input (segmentationrequest). By setting bit 13 to zero, the APU 52 can disable the targetedPRPC 58a from accumulating credit. All PRPC 58as are disabled at systemreset and must be enabled by the APU 52 prior to activating a PRPC 58a.

In addition, a function is provided by the PRU 58 to allow the APU 52 tostall one or more of the PRPC 58as at any given time. An eight bit StallRegister 58d is written by the APU 52 using a store instruction. The APU52's data bus carries the Stall Register Mask on bits seven throughzero. Writing a one into a bit of this register will force thecorresponding PRPC 58a to stall until the one is overwritten by a zeroduring a subsequent APU 52 write operation.

A special provision is added to ensure that a PRPC 58a does not stall attime-out so software need not concern itself with a PRPC 58a stalledgenerating credit indefinitely. When the APU 52 writes a new value intothe PRPC 58a's initialization register, that value will be loaded intothe PRPC 58a once the PRPC 58a reaches zero.

If the APU 52 wishes the effect to take place immediately (overwrite theexisting value in the PRPC 58a), it asserts the immediate bit encoded asAPU address bit 9. If APU address bit 9 is set during a write to aninitialization register, the initialization value is written into boththe initialization register and the PRPC 58a. If APU address bit 9 isnot set, the initialization value is loaded only into the initializationregister and will be loaded into the PRPC 58a only once the PRPC 58atimes out.

USING PRPC 4/5 AND 6/7 AS 24 BIT TIMER/COUNTERS

PRPCs four and five and PRPCs six and seven are capable of beingconverted into general purpose 24 bit timer/counters. When configured intimer/counter mode, the PRPCs 58a can be read and written by theprocessor. PRPCs four and five are configured into one 24 bit timercounter by setting the COUNTER 4/5 bit in the System Control Register.PRPC five makes up the high order 12 bits of the counter and PRPC fourmakes up the low order 12 bits.

PRPCs six and seven can be used in a similar fashion. When configured incounter/timer mode, PRPCs 4, 5, 6 and 7 timing out will not cause CpCond2 to be asserted but they will continue to accrue credit in the creditregister 58b. Once both PRPCs 58a making up a 24 bit timer counter havecounted down to zero, an interrupt will be sent to the APU 52.Timer/counter 4/5 is connected to the APU 52's interrupt 0 input andtimer/counter 6/7 is connected to the APU 52's interrupt 1 input.

The interrupt assertion can be cleared by the APU 52 by clearing theassociated bit/s in the Channel Group Credit Register 58b. Whenconfigured in timer/counter mode, most of the control features listedabove still apply. PRPCs 4 and 6 are still affected by the externalPRU₋₋ CountDisable input (if so configured in initialization registerbit 12), but PRPCs 6 and 7 are forcibly removed from PRU₋₋ CountDisablesensitivity. Since in timer/counter mode the count enable inputs ofPRPCs 5 and 7 are connected to the time out (credit bits) of timers 4and 6, respectively, timers 5 and 7 effectively stall in response toPRU₋₋ CountDisable if their associate low order partners are configuredto be sensitive to PRU₋₋ CountDisable.

3.4.2 Global Pacing Rate

Average and Peak Rate Pacing and Burst Length are useful constructs inmanaging bandwidth utilization by a particular VC. Taken as a whole, OAMsoftware can manipulate these values for active VCs to manage theoverall data throughput rate (or information rate) on the Transmissionline. However, it is almost impossible to effectively shape the overallATM port information rate through this mechanism. Shaping of the overallinformation rate may be desirable when connecting into a system that canonly handle a limited information rate or during periods of highcongestion in the switching network.

In the case of a congested network, the latency between notification ofcongestion and the host processor's ability to modify the pacingparameters may be high. As a result, many cells will be sent into acongested network and lost, requiring the retransmission of manyCS-PDUs. This further exacerbates the congestion problem. And by thetime the system responds to the notification of congestion, thecongestion situation in the network may have actually changed. That iswhy the ATMizer 50 implements a Global Pacing Rate Controller functionas illustrated in FIG. 9. The Global Pacing Rate Control function is aquick way to limit the overall transmission bandwidth consumed on theTransmit port. The Global Pacing Rate Register (GPRR) 58c, asillustrated in FIG. 8, is an APU 52 accessible register that determinesthe percentage of cells sent out over the ATMizer 50's PCI Transmit portthat can be assigned cells (the remainder being IDLE cells). Anyassigned cell percentage can be chosen as long as it is a multiple of12.5% between 0% and 100%.

A single APU instruction is all that is required to modify the GPRR 58c.With the GPRR 58c, the ATMizer 50 is able to throttle the data rate onits transmission port within the same cell time that the congestion isrecognized from an incoming cell. And more importantly, the amount ofthe initial reduction as well as the algorithm by which the ATMizer 50returns to full speed operation can be implemented intelligently in APU52 firmware and can be modified as more is learned about ATM networkcongestion.

Furthermore, high priority channels can continue to gain access to thereduced throughput capacity while lower priority traffic will beblocked.

3.4.3 Channel Priority

Software can use the CGCR 58b to implement channel priority. By checkingthe CGCR bits in a particular order, the APU 52 implements "highpriority" and "low priority" channel groups. In an effort to give evenfurther priority to CS-PDUs/VCs belonging to "high priority" channelgroups, the APU 52 can read the CGCR 58b periodically during theservicing of a channel group designated by software convention as "lowerpriority" to see if a higher priority channel group has timed-out duringthe servicing process.

If so the APU 52 can suspend servicing of the "lower priority" channelgroup and begin servicing the "higher priority" channel groupimmediately. The APU 52 can then resume servicing of the lower prioritychannel where it left off once all higher priority requests have beensatisfied.

In addition, if the user wishes to attach both high and low priorityCS-PDUs to a single PRPC 58a in order to pace high and low priorityCS-PDUs/VCs at the same Service Interval Rate, he can. Each PRPC 58acould have two (or more) Channel Groups associated with it.

For instance a PRPC 58a could have a high priority channel group and alow priority channel group attached to it. The APU 52 could service allchannels belonging to the high priority channel group and then check forother high priority requests pending by reading in the CGCR 58b beforeservicing the low priority channel group attached to that particularPRPC 58a. Virtually any "channel priority" algorithm can be supported inuser firmware. There are no priority mechanisms enforced in hardware.

In summary, the Pacing Rate Unit 58 consists of the 8 Peak Rate PacingCounters 58a, the Channel Group Credit Register 58b (as illustrated inFIG. 10), the external count disable feature (PRU₋₋ CountDisable), thelogic that asserts CPCond2 when one or more bits are set in the CGCR 58band the hardware to allow the processor to set the PRPC 58ainitialization values and to clear the Channel Group Credit Register 58bbit fields as Channel Groups are serviced. All other constructs are bysoftware design and make use of one or more of the hardware featureslisted above.

Regarding Channel Priority Vs CS-PDU Priority, PRPCs 58a and theirassociated Channel Group or Channel Groups can be given distinctpriorities. If Channel Groups have reached their Service Intervals andare awaiting servicing, high priority requests can be serviced beforelow priority requests. Existing high priority requests should beserviced before new high priority requests.

New high priority requests may be serviced before existing low priorityrequests. This implementation of "channel priority" is separate from theAAL5 high-medium-low CS-PDU Priority assignment. Both priorityconstructs influence the cell generation process.

Channel priority affects Channel Group/CS-PDU servicing sequence whileATM AAL 5 CS-PDU priority is reflected in the PTI and CLP field valuesof the ATM header. Both functions are controlled by the ATMizer 50. ForAAL 5 traffic, the host must include an indication of the CS-PDUpriority in the "Segment CS-PDU" message packet provided to the ATMizer50.

3.5 DMA Controller 60

As illustrated in FIG. 11, the DMA Controller 60 is an assembly ofregisters, counters and a data path that collectively control datatransfer operations between the on-chip VCR 56 and main memory. Thesetransfers include the retrieval of SAR User Payloads from memory basedCS-PDUs during segmentation operations, the writing of SAR User Payloadsback into memory based CS-PDUs during reassembly operations, access tobuffer lists, link list pointers, messages and all other data structuresrequired by the user's application.

In addition, in systems that support more simultaneously active VCs thancan be supported directly out of the on-chip VCR 56, the DMA controller60 can be used to retrieve and restore memory based channel parameters.The DMAC 60 also contains CRC32 generation circuitry that is used togenerate the CRC32 values required for AAL5 CS-PDU protection. All DMAregisters and counters are initialized by the APU 52 and all DMAoperations are initiated by the APU 52 as part of the standard servicingof events such as "Cell Received" and "Peak Rate Pacing CounterTime-Out".

Because the DMAC 60 is configured at the start of each DMA operation, iteffectively provides an unlimited number of DMA channels. The followingsection describes the DMAC registers and counters pictured above in moredetail.

3.5.1 DMAC Control Registers and Counters

MAR Memory Address Register rt(31:24)

The Memory Address Register holds the 8 MSBs of the main memory addressduring DMA operations. While the DMAC does increment the main memoryaddress for consecutive transfers in a multiple word DMA operation, itdoes not increment the 8 MSBs (i.e. the value in the MAR). Therefore, ifexternal logic relies on sequential incrementing of the DMA₋₋ Addressbus during multiple word DMA operations, the APU 52 should not initiatea DMA operation that crosses a sixteen megabyte boundary. The contentsof the MAR are reflected on output pins DMA₋₋ Address(31:24) when inputpin DMA₋₋ AdrOEx is asserted.

MAC Memory Address Counter rt(23:2)

The Memory Address Counter holds the lower 22 main memory address bits.During a DMA operation, the Memory Address Counter is incremented inresponse to the assertion of DMA₋₋ RdWrAck by external logic. Thecontents of the MAC are reflected on DMA₋₋ Address(23:2) when DMA₋₋AdrOEx is asserted.

MOR Memory (byte) Offset Register rt(1:0)

The Memory Offset Register holds the two LSBs of the main memory addressof a DMA operation. The DMAC will begin the memory access beginning atthe byte pointed at by the MOR. The DMA₋₋ Bmask(3:0) outputs indicatewhich bytes should be retired to memory during DMA transfers. Theaddress of the first word of the operation is indicated by the MAR/MAC.

LAC Local Address Counter ea(11:2)

The Local Address Counter holds the on-chip VCR 56 read or write wordaddress (the "local address"). It is programmed by the APU 52 with thelocal starting address at the beginning of a DMA operation and thenincremented automatically by the DMAC 60 as the operation proceeds.

LOR Local (byte) Offset Register ea(31:30)

In applications supporting AAL 3/4 Segmentation and Reassembly or inapplications supporting "Scatter" and "Gather" operation, it may benecessary to transfer a data block between the VCR 56 and main memorythat does not begin on an even word boundary in the VCR 56. The LocalAddress Offset field informs the DMA controller 60 of the starting byteoffset of the first byte of valid data in the VCR 56. The LAR providesthe word address of this first byte.

TLC Transfer Length Counter ea(29:24)

The size (in bytes) of a DMA transfer is set by the APU 52 in the TLC.Since the TLC is only a six bit register, a 64 byte transfer lengthencoding is recognized when the TLC is initialized to 000000.

G Ghost Bit ea(21)

The ghost bit is used to indicate to external circuitry that the DMAoperation being requested is being done solely for the purpose ofcreating a CRC32 partial result for an AAL 5 SAR SDU that has beenconstructed in the VCR 56 from two or more data block fragments. If aSAR SDU is built from more than one data block, and if one of the datablocks was not word aligned and of size evenly divisible by four, theCRC32 partial generator in the DMAC would not have been able tocalculate a CRC32 partial result for the SAR SDU over the numerous DMAoperations required to retrieve the sub blocks of the SAR SDU.

Therefore, once the entire SAR SDU has been built up in the VCR 56, theAPU 52 will have to force a CRC32 partial generation by initiating a DMAwrite operation targeting the SAR SDU as the local write data. The CRC32generator can then calculate the need CRC32 partial result for this SARSDU. The write is not truly desired and so the APU 52 sets the ghost bitto inform the memory controller that this write should be acknowledgedat full speed but should not affect the contents of memory.

The memory controller responds by ignoring the transaction accepts forprovide the necessary number of DMA₋₋ RdWrAck assertions to move the 48byte SAR SDU through the CRC32 generator. Once the operation iscomplete, the APU 52 can read out the result.

D DMA Operation Direction ea(20)

The DMA Operation Direction Register is a one bit register that is usedto indicate to the DMAC 60 and the outside world the direction of theDMA operation. By writing a 1 into this register the APU 52 indicatesthat it wishes to perform a main memory read operation. A zero indicatesa main memory write operation. The value of this register is directlyreflected on output pin DMA₋₋ RdWrx.

CRC32 Partial Register rt(31:0)

The CRC32 Partial Register should be initialized to all ones by the APU52 prior to beginning the first SAR User Payload retrieval for an AAL 5CS-PDU. The CRC32 Partial Result, generated during the DMA operation, isread from the CRC32 Partial Register by the APU 52 at the end of the DMAoperation. It is saved and then restored prior to the next segmentationoperation. The register is used in a similar fashion for CRC32generation during reassembly.

WWW₋₋ DMA ea(19:16)=0100

Internal logic asserts this signal when the APU 52 executes a Store Wordinstruction that carries 0100 on APU 52 address bits 19:16,respectively. This causes the values on the APU 52 address and data busto be written into the appropriate DMA control registers and counters.It also results in the assertion of the DMA₋₋ Rqst output signal andinitiation of the DMA operation.

3.5.2 Programming the DMAC 60

In order to initiate a DMA operation between main memory and the on-chipVCR 56, the APU 52 programs the DMAC 60 with the starting main memoryaddress (byte address), the local/VCR 56 starting address (word alignedaddress written into the LAR and the starting byte offset within thetargeted word written into the LOR), the number of bytes to betransferred and the direction of the transfer.

In addition, the APU 52 may need to preset the CRC32 generator for AAL 5CS-PDU CRC32 support or set the ghost bit as needed.

The APU 52 can configure the DMAC control registers and counters andinitiate a DMA operation by executing a single "Store Word" instructionas illustrated in FIG. 12. Both the effective address and data fieldsproduced by the Store Word instruction are used to configure the DMAC'sregisters and counters.

For AAL5 CS-PDU segmentation and reassembly, if the ATMizer 50 is to beused for CRC32 generation and checking, a second "Store Word"instruction is needed as illustrated in FIG. 13 to initialize the CRC32generator with the correct CRC32 partial result value.

This second instruction should be executed immediately before the StoreWord instruction that is used to initialize the DMAC's registers andinitiate the DMA operation. The CRC32 Partial register can be read atthe end of a DMA operation using a Load Word instruction withEA(19:16)=0101 as illustrated in FIG. 14.

The 16 bit offset is sign-extended and added to the contents of generalregister rb to form a 32-bit unsigned effective address. The contents ofgeneral register rt are stored at the memory location specified by theeffective address. If either of the two least significant bits of theaddress is non-zero, an address exception occurs.

3.5.3 Using the DMA Controller 60 to implement Cell Switching,Segmentation and Reassembly

The ATMizer 50, under APU 52 user firmware control, can be used toimplement CS-PDU segmentation, CS-PDU reassembly, and ATM cellswitching. On a per VC basis, the APU 52 can decide whether to switch orterminate an incoming cell. The decision can be based on staticprinciples (certain VC #s are dedicated to switched VCs while other VC#s are dedicated to terminating VCs) or on dynamic principles (thechannel parameter entry for a given VC has a flag field that indicateswhether its cells should be switched or terminated).

REASSEMBLY VS. CELL SWITCHING

If an incoming cell is to be "switched", it can be passed, headers andtrailers intact, to any memory mapped device using the ATMizer 50's DMAController 60 to accomplish the transfer. In networks implementing aring-like structure or a simple two way switching matrix, incoming cellscan be switched directly between the ATMizer 50's Receiver 62b andTransmitter 62a by simply passing a pointer to the cell in the VCR 56(i.e. the cell's VCR 56 starting address) to the Transmitter in the PCI62 (this is the same procedure that is used for queuing a cell fortransmission). In this fashion, cells can be switched within the ATMizer50, never touching system memory.

Before a cell is switched, the APU 52 may choose to perform operationson it such as VPI translation, VCI translation, and congestionnotification insertion. The APU 52 accomplishes these actions by simplyoverwriting the specific fields in the cell with new values. Forexample, if VCI translation is required, a flag will be set in thechannel parameter entry for the VC that the cell arrived over thatindicates that the cell is to be switched w/VCI translation.

The new VCI will be included in the channel parameter entry as well. TheAPU 52 reads the new VCI from the channel parameter entry and writes itinto the VCI field of the cell held in the VCR 56 (remember that the VCR56 holds either two, four, eight or sixteen 64 byte cells. The Receiver62b in the PCI 62 writes cells into the VCR 56 in a modulo two, four,eight or sixteen fashion). A decision is then made to switch the cellover the backplane using the DMA controller 60 or to pass a pointer tothe cell to the ATM Transmitter 62a in the PCI 62.

In practice, the specific procedures for implementing cell switching aredefined by user firmware. From the perspective of the DMA controller 60and the Parallel Cell Interface 62, there is no distinction between cellswitching and circuit termination. Cells arriving over the ATM Receiver62b are written into the VCR 56.

In the case of circuit termination, the APU 52 initiates a DMA operationto transfer the User Payload portion of a cell to its correspondingmemory based CS-PDU and sets the LAC, LO and TLC values in the DMAC 60accordingly. In cell switching applications where a cell is to betransferred to a memory mapped device, the entire cell, headers andtrailers included, must be transferred.

Therefore, the pointer written into the LAC should point to thebeginning of the cell instead of the beginning of the SAR User Payloadfield, the Local Offset is most likely zero since the Receiver writescells into the VCR 56 starting at byte 0 of word zero for the activeReceived Cell Holder, and the TLC value should be large enough toinclude all ATM and SAR headers and trailers.

FIG. 15 illustrates the local address pointers (labeled B) that would bewritten into the DMAC's Local Address Counter, Local Offset Register andTransfer Length Counter to accomplish reassembly operations on 52 and 60byte cells as well as the pointers (labeled A) that would be writteninto these same registers to accomplish switching operations on 52 and60 byte cells.

In addition, the drawings illustrate that in the case of AAL 3/4 cells,the SAR User Payload is not word aligned Offset field to 10 wheninitiating the DMA transfer to inform the DMA Controller 60 of thealignment condition.

The DMA controller 60 is responsible for merging bytes from two VCR 56words into a single word to be written to a word aligned data structurein main memory. If the MOR indicates that the targeted memory address isnot word aligned, the DMA controller 60 is also responsible foradjusting the targeted local data to the proper memory alignment.

The DMAC 60 has the capability to transfer from any local offset to anymemory offset and vice versa. This is especially important in AAL 3/4S&R operations, AAL 3/4 and AAL 5 "Gather" operations and in AAL 3/4 orAAL 5 "Scatter" operations where the system designer wishes to rely onthe ATMizer 50 to do higher layer (i.e. TCP/IP) header stripping andPacket alignment to accelerate application layer routines. Whenswitching AAL 3/4 Cells the Local Offset should be set to 00 becauseeven though the SAR User Payload field is misaligned, the cell itself isnot.

SEGMENTATION VS. CELL SWITCHING

Cell switching and segmentation differ from the perspective of the DMAC60 in a similar fashion. Fetching a cell from memory differs fromfetching a SAR User Payload from memory in both the size of the transfer(i.e. a cell is larger than a SAR SDU) and the LAC and LO initializationvalues. In addition, segmentation is usually triggered by an on-chipevent such as a Peak Rate Pacing Counter 58a timing-out while the needto switch a cell from an external memory mapped device must be indicatedto the APU 52 using an external triggering event.

The relationship between CS-PDU main memory addresses and VCR 56 cellholder us illustrated in FIG. 15. The addresses are for a standard 52byte cell and a user specific 60 byte cell.

3.5.4 CRC32 Generation Considerations

CRC32s can be calculated individually for each CS-PDU activelyundergoing either segmentation or reassembly. For CS-PDUs undergoingsegmentation, the final CRC32 result is appended, under APU 52 control,to bytes 44-48 of the SAR SDU of the last cell generated from theCS-PDU. For CS-PDUs undergoing reassembly, the CRC32 result is comparedwith the CRC32 received in the last cell of the CS-PDU as a checkingmechanism.

Because the ATMizer 50 supports cell multiplexing and de-multiplexingfrom up to 64K VCs, the APU 52 must provide CRC32 partial result storageand retrieval services to allow for multiple concurrently active CRC32calculations to be performed by the single CRC32 generator.

As part of its Partial Results Management function the APU 52 must setthe CRC32 Partial Register to all ones prior to retrieving the first SARSDU for an AAL5 CS-PDU. The 12 word DMA Read operation automaticallygenerates a 32 bit CRC32 partial result in the CRC32 Partial Register.The APU 52 must retrieve this value at the end of the DMA operation andsave it to preset the CRC32 Generator prior to the next transfer fromthe same CS-PDU.

If more than one cell is to be built from a CS-PDU before proceeding tothe next CS-PDU (i.e. burst length >1), and if no other DMA operationtakes place in the interim, the APU 52 need not retrieve and restore theCRC32 partial result until the final SAR SDU has been retrieved from theCS-PDU. Before proceeding to the next CS-PDU, the AAL5 CRC32 partialresult must be stored safely away in a place where it can be retrievedthe next time that the CS-PDU is segmented (it will most likely bestored in the channel parameter entry for the VC).

When the last SAR User Payload of a CS-PDU has been fetched from memory,the APU 52 is responsible for reading the CRC32 final result from theCRC32 Partial Register and appending the result to the last four bytesof the cell in the VCR 56 Cell Builder. If the final DMA transfer is setas a 48 byte transfer, user software must be sure that the last fourbytes of the CS-PDU in main memory (i.e. the CRC32 field) is preset toall zeros. If the last transfer is executed as a 44 word transfer, nosuch restriction applies.

On reassembly, the APU 52 must preset the CRC32 register with all onesprior to initiating the first reassembly DMA operation for a CS-PDU. TheAPU 52 is again responsible for retrieving the CRC32 partial result atthe end of the DMA operation, saving it away in the VCR 56 or systemmemory (where ever channel parameter entries are saved) and restoring itprior to reassembling the next cell of the CS-PDU. Again, if the lasttransfer is queued up as a 48 byte transfer the APU 52 must first setthe CRC32 field in the Cell Holder to all zeros before initiating theDMA operation.

At the end of the last transfer, the APU 52 reads the CRC32 final resultfrom the CRC32 partial register and compares it to the result carriedinto the ATMizer 50 in the last cell of the CS-PDU. If they differ, aCRC32 error has been detected and the ATMizer 50 must inform hostsoftware utilizing the user's messaging system.

3.5.5 Misaligned Operations Revisited

As mentioned above, the DMAC 60 in the ATMizer 50 is capable ofperforming a DMA operation of any byte length less than or equal tosixty four bytes beginning at any VCR 56 byte offset and beginning atany memory byte offset as well.

For example, during segmentation implementing "Gather", if twophysically disjunct data structures form a single logical AAL 5 CS-PDU,one being 53 bytes and a second being 91 bytes (87 bytes of significanceand a four byte zeroed out CRC32 field to be calculated and inserted bythe ATMizer 50), the ATMizer 50 must perform the following operations toaccomplish segmentation of this disjunct CS-PDU:

    ______________________________________                                        Assumptions                                                                   1. CS-PDU fragment one (53 bytes) starts at memory                            address 00000000H.                                                            2. CS-PDU fragment two (91 bytes) starts at memory                            address 00001000H.                                                            3. Next active Transmit Cell Builder in the VCR 56                            starts at 0100H.                                                              Procedure                                                                     1. Build first cell.                                                          MAR-MAC-MOR = 00000000H SAR SDU retrieval                                     TLC = 48D SAR  SDU will be placed                                             starting at 0104H                                                             LAR = 0104H  Received Cell Holder Starts                                      at 0100H                                                                      LO = 00H  ATM Header will be placed                                           at 0100H                                                                      2. Build next cell (a fragment transition cell).                              MAR-MAC-MOR = 00000030H  Get remainder of first                               fragment                                                                      TLC = 5D  Use next Transmit Cell                                              Builder                                                                       LAR = 0144H                                                                   LO = 00H                                                                      MAR-MAC-MOR = 00001000H  Fill SAR SDU from second                             fragment                                                                      TLC = 43D                                                                     LAR = 0148H                                                                   LO = 01H                                                                      3. Build final cell                                                           MAR-MAC-MOR = 0000102BH  Get remainder of second                              fragment                                                                      TLC = 48D                                                                     LAR = 0184H                                                                   LO = 00H                                                                      ______________________________________                                    

A problem of special significance when building AAL 5 transition cellsis the fact that the CRC32 generator will be thrown off track by the gapin the data stream used to build the cell. If a cell is built from oneor more word aligned data structures and if a data structure is alwaysan even multiple of four bytes, CRC32 generation is not impactedgreatly.

User firmware simply retrieves the CRC32 partial result from the firstdata fetch (i.e. in step two if the first data fetch were 8 bytesinstead of 5 bytes) and restores it to the CRC32 generator prior toundergoing the second data transfer (i.e. 40 bytes instead of the 43bytes shown above in step 2). In this fashion, the CRC32 generationprocess proceeds without a problem.

If however, the Gather function involves data structures that requirenon-word-aligned accesses, as shown in step 2 above, the CRC32 generatorwill be thrown out of alignment (because the CRC32 generator operates on32 bits of data at one time). Therefore, firmware must first constructthe SAR SDU in the VCR 56 completely, using as many data structures asrequired to fill out the body of the cell and without regard to datastructure alignment, before asking for a CRC32 calculation.

Once the SAR SDU has been constructed in the VCR 56, the CRC32 partial(or final) result is calculated by initiating a "Ghost" DMA writeoperation to an arbitrary address. The DMA ghost operation actsinternally like a memory write operation. The DMAC 60 can be movedthrough a Ghost write operation at a rate of one word per cycle. Oncethe operation has completed, the CRC32 value can be read from the CRC32partial register the same as for any AAL5 DMA Segmentation procedure.

Since the CRC32 generator works on aligned data (data after it passesthrough the DMAC's byte aligners), future cells built from the finalCS-PDU fragment will not require ghost operations. CRC32 generation willproceed smoothly as long as another unaligned boundary condition is notencountered.

On reassembly operations, if Header stripping and data field alignmentis employed for application acceleration, the same issues may arise withcells that contain the end of one header and the data field of a packet.On reassembly, the CRC32 generator works on VCR 56 data before it hitsthe data aligners. Therefore, after the ghost operation is done togenerate the CRC32 for the transition cell, future operations to asingle fragment need not utilize ghost operations because the SAR SDUwill be word aligned in the VCR 56 even though it may not be wordaligned after being written into main memory.

That is why the CRC32 generator pulls its input data prior to the dataaligners in the memory write direction and following the data alignersin the memory read direction. (The CRC32 generator uses data aligned toits VCR 56 destination alignment, not based on memory alignment. This istrue in both directions).

3.5.6 Using the DMA Controller 60 to Implement Scatter and GatherOperations

By construction, the ATMizer 50 provides the system design with all ofthe functionality needed to implement a fully robust scatter-gather ATMnetwork <-> Host interface. In the Gather direction (duringsegmentation) the ATMizer 50 is capable of generating cells from anynumber of separate data structures as if they were a single contiguousCS-PDU. By doing so, the ATMizer 50 precludes the need for the hostprocessor to do a series of time consuming data movement operations toform a contiguous CS-PDU in a local buffer memory prior to initializingthe Segmentation operation.

For example, in a TCP/IP application, the TCP/IP header may reside in adifferent location within host memory from the actual user CS-PDU datapayload. In addition, the actual CS-PDU data payload field may actuallyconsist of a number of discontinuous pages of memory. Because theATMizer 50 supports "Gather" operations, there is no need to move all ofthese data structures in advance into a single CS-PDU.

The actual implementation of both Scatter and Gather are up to userfirmware. In general, the Gather function can be implemented by havingthe host processor pass to the ATMizer 50 a series of "Segment CS-PDUfragment" messages with the appropriate user defined control structures.The APU 52 recognizing that it is involved in a gather operation, isprogrammed not to generate end of CS-PDU header fields at the end of aCS-PDU fragment.

It is also programmed to understand how to resolve the arrival at an endof CS-PDU fragment boundary (i.e. automatically resolve the link listpointer or simply pass a message to the host processor asking it toresolve the next pointer for it).

3.5.7 How to Determine when a DMA Operation Has Completed

The APU 52 must determine that a DMA operation has completed before itattempts to use the information retrieved by the DMA operation. In thecase of segmentation, the APU 52 must determine that the DMA controller60 has retrieved the entire SAR SDU before it can queue the cell fortransmission. In systems where channel parameter entries are kept offchip, the APU 52 must wait for the DMA controller 60 to return thechannel parameter entry before attempting to access it.

There are three methods for the APU 52 to determine when a DMA operationhas completed.

1. "Branch on Coprocessor Condition 3 True"

The DMA controller 60 generates a DMA₋₋ Busy internal signal whenever itis involved in a DMA transfer. DMA₋₋ Busy is connected directly to theAPU 52's CPCond3 input pin.

Programmers familiar with the R3000 CPU architecture understand that thefour CpCond inputs to the R3000 can be tested using a conditional branchinstruction. If the APU 52 wished to determine if the DMAC is busy, itcan execute a "Branch On Coprocessor Condition 3 True" instruction. IfCPCond3 is True (i.e. DMA₋₋ Busy is asserted), the DMA Controller 60 isstill busy and the APU 52 should not attempt to use the data (i.e. queuethe cell for transmission). If CPCond3 is False (i.e. DMA₋₋ Busy is notasserted) the DMA controller 60 has finished its operation and the datais valid in the VCR 56.

The APU 52 is free to queue the cell for transmission or read theretrieved data from the VCR 56. If the APU 52 wishes to check that anentire AAL 5 SAR SDU has been fetched from memory before queuing thecell for transmission, it can execute a "Branch on Coprocessor Condition3 True" instruction where the branch target address is the "Branch onCoprocessor Condition 3 True" instruction itself.

While the DMAC 60 remains busy, this test evaluates as True and the APU52 loops continuously. Once the DMA operation has completed the testwill be evaluated as false and the CPU will fall out of the loop. Thenext instructions could be the instructions that queue the cell fortransmission and jump back to the event parsing routine.

2. "Load w/DMA Busy Considerations, Type 1":

Another scenario exists when the application chooses not to cachechannel parameters on-chip. In such a scenario, the APU 52 must gainaccess to a channel parameter entry in main memory before initiating aSAR SDU DMA operation or Cell Switching operation. The APU 52 mustinitiate a DMA operation to retrieve the channel parameter entry, usethese parameters to build one or more cells, update the channelparameters (i.e. DMA address and Byte Count) and restore the updatedparameters to main memory.

In systems using aggressive memory system designs, these channelparameters can be fetched quickly enough to maintain peak ratethroughput. However, if several cells are built and sent for eachchannel, the overhead associated with the retrieval and restoration ofthese parameters can be amortized over several "Cell Times" minimizingits impact on transmission throughput in systems with slower memorystructures. The ideal scenario is, of course, the caching of channelparameters in the VCR 56.

In situations where channel parameter entries are stored in main memoryinstead of the VCR 56, the APU 52 must be able to sense when the DMAoperation used to retrieve the entry has completed. The DMA engine canaccomplish this as before with the "Branch on Coprocessor 3 True"instruction or it can accomplish it in a more efficient manner.

Since at some point the APU 52 will need the channel parameter entryinformation to proceed, the APU 52 can execute a "Load" instruction witha target address equal to the beginning LAC address of the DMAoperation. In the normal scenario, a load to the VCR 56 is decoded as0000 in effective address bits (19:16), by placing a "1" in address bit22, internal logic will stall the CPU load operation until the firstword of the DMA operation has been retired to memory (we will call thisa "Load w/DMA₋₋ Busy Consideration, Type 1" instruction).

The benefit of this stalling mechanism is that if the first word isavailable, no cycles are lost and if the first word is not available,the CPU will stall but then immediately recover as soon as the word isretrieved from memory. And of equal importance, the CPU will haveaccomplished the access as well.

The Branch on Coprocessor 3 True method requires at least twoinstructions to test the condition and does not result in any transferof the desired information to the APU 52 register file. Therefore, "Loadw/DMA Busy Considerations, Type 1" is a far more efficient way ofaccomplishing the test.

3. "Load w/DMA Busy Considerations, Type 2":

Under normal circumstances, it is assumed that once the first word isretrieved from memory, the remainder of the words will be retrieved in adeterministic fashion (one every cycle or one every other cycle).Firmware could then simply pace further reads of the information.

To support systems where DMA transfers could be interrupted in themiddle of the operation, the ATMizer 50 also supports a "Load w/DMA BusyConsiderations, Type 2" instruction. This differs from the "Load w/DMABusy Considerations, Type 1" instruction in that it forces an APU 52stall if the DMA controller 60 is busy. The first instruction onlyforces a stall if the DMA Controller 60 has yet to retrieve the firstword of the transaction.

This is a useful mechanism to guard against situations where there maybe an unpredictable amount of time between retrieval of the first wordof a DMA transaction and the remaining words. "Load w/DMA BusyConsiderations, Type 2" is indicated to internal hardware when EffectiveAddress Bit 23 is set to a 1 during Load or Store instructions involvingthe VCR 56 as the target.

ADDITIONAL DMA STALLING OPERATIONS

If the APU 52 attempts to program a DMA operation into the DMAcontroller 60 before the DMA controller 60 has completed a pendingoperation, the DMA engine will assert the CPU stall input forcing theCPU to stall until the DMA operation has completed. As soon as theexisting operation completes, the new operation will be loaded into theDMAC 60.

DMA₋₋ Rqst will not go low in the case of back to back operations. Thisallows the ATMizer 50 to indicate that it does not wish to give up thebus at the completion of the DMA operation. External logic shouldmonitor the DMA₋₋ OpEnding output to distinguish between separate DMAoperation boundaries.

3.6 Parallel Cell Interface (PCI) 62

The Parallel Cell Interface 62 contains the ATM port side Transmitterand Receiver functions as illustrated in FIG. 16. The PCI's Transmitter62a is responsible for taking cells that have been built in the VCR 56and transferring them one byte at a time to an external ATM lineserializer/transmitter. The Transmitter 62a also generates and insertsthe HEC and generates and appends a CRC10 field to AAL 3/4 cells.

The Transmitter 62a is also responsible for Cell Rate Decoupling. Ifthere does not exist an assigned cell in the VCR 56 ready fortransmission, the Transmitter 62a will automatically send an IDLE cell.The Receiver 62b accepts cells, one byte at a time, from the ATM lineparallelizer/receiver and reconstructs these cells in the VCR 56 so thatthe APU 52 may process them (either reassemble the cell or switch thecell).

The actual size of a cell is user programmable, up to 64 bytes, tosupport applications that employ extra header fields to convey switchspecific information. The actual size of the cell must be a multiple of4 bytes.

The typical ATM cell is represented in the VCR 56 as a 52 byte entity.The HEC value is generated and inserted into the cell as it is passedout of the ATMizer 50. Therefore, the typical ATM cell adheres to therequirement that it be a multiple of 4 bytes. If the user employees acell size other than 52 bytes, he must disable HEC generation andchecking and he shall be responsible for generating and checking the HECvalue externally.

3.6.1 Parallel Cell Interface Transmitter 62a

The Transmitter 62a in the Parallel Cell Interface 62 is responsible fortransferring cells from the VCR 56 to the ATM Transmission ConvergenceSublayer framing logic utilizing the ATMizer 50's eight bit wide PCI₋₋TxData(7:0) output bus. Cells become available for transmission in theVCR 56 in one of three ways.

3.6.1.1 Transmit Cell Sources

1. Segmentation: In response to an internal or external event, the APU52 determines that it must segment one or more CS-PDUs or generate acell from one or more Real Time data buffers. The APU 52 chooses anavailable Transmit Cell Holder to be used in the cell building process(as described in section 2.3.0). In order to accomplish segmentation,the APU 52 initiates a DMA Read Operation to transfer the SAR SDU from amemory based CS-PDU or Real Time Data Buffer into the VCR 56.

The APU 52 is careful to provide the DMA controller 60 with all of theproper address information such that the SAR SDU is transferred into theTransmit Cell Holder in its proper cell location. The APU 52 thengenerates or retrieves and appends the necessary headers and trailers tothe cell and queues the cell for transmission. The APU 52 queues thecell for transmission by writing the VCR 56 starting address of the cellinto the Transmitter's Cell Address FIFO.

2. Internal Switching: The ATMizer 50 is capable of transferring cellsthat arrive over the ATM port side Receiver (PCI₋₋ RcData(7:0)) out ofthe ATMizer 50 utilizing the ATM port side Transmitter without having topass the cell to main memory. This process works as follows.

All cells arriving into the ATMizer 50 over the ATMizer 50's ReceiverPort are written into the VCR 56. The ATMizer 50 sets aside the first512 bytes (8 Cells) or 1024 bytes (16 Cells) of VCR 56 memory forReceived Cell Buffering.

Once a cell is written into the VCR 56 the APU 52 must process the cell.As with all operations, the APU 52 uses cell header fields as an indexinto a VCR 56 or memory based look up table that contains information onhow the cell should be processed. If the look up yields information thatindicates that the cell should be sent out over the ATM port sideTransmitter, the APU 52 can perform any necessary header manipulationoperations (such as VCI or VPI translation and/or congestionnotification insertion) before queuing the cell for transmission. TheAPU 52 queues the cell for transmission by writing the VCR 56 startingaddress of the cell into the Transmitter's Cell Address FIFO.

3. External Switching: In certain applications, the ATMizer 50 will haveaccess to main memory based cells that have arrived over some other ATMport but need to be transferred out over the ATMizer 50's ATM port sideTransmitter. The ATMizer 50 is informed of the need to switch a mainmemory resident cell through some user defined external event mechanism(through assertion of ATMizer₋₋ Int or through APU 52 polling of somemailbox location).

If the ATMizer 50 finds that a cell exists externally (the location ofwhich is likely to be known by convention), it can initiate a DMAoperation to bring the cell into the ATMizer 50. Once inside, the cellheaders can be modified by the APU 52 (or they may have already beenmodified by the "ATMizer" that placed the cell in external memory). Oncethe cell has been fully retrieved from memory and placed in the VCR 56,the APU 52 queues the cell for transmission by writing the VCR 56address of the cell into the Transmitter's Cell Address FIFO.

3.6.1.2 Queuing a cell for transmission

As described above, Transmission Cells can be generated in one of threefashions. What is common to each of the scenarios listed above is thatthe APU 52 queues a cell for transmission by writing an address pointerinto the PCI Transmitter 62a's Cell Address FIFO. This address pointerpoints to where the cell begins in the VCR 56.

The address is passed through the use of a Store Word Instruction withEffective Address Bits (19:16)=1100. The address itself is conveyed tothe Cell Address FIFO over the CPU's Data Bus (CPUDATA(11:6)). Theaddress should be 64 byte aligned (i.e. CPUDATA(5:0) should=000000).

If the APU 52 attempts to write an address to the Cell Address FIFO butthe Cell Address FIFO is already full, the write operation will causethe APU 52 to enter a stall operation and the APU 52 will remain in thestall operation until the Transmitter finishes sending a cell and alocation becomes available in the Cell Address FIFO. The APU 52 canprevent writing an address into a full buffer (and prevent the delaysassociated with it) by testing the state of the buffer before beginninga segmentation or cell switching application.

As explained previously, the APU 52 learns of an internal event (PRPC58a time-out) by polling its CPCond2 input (Segment₋₋ CS-PDU₋₋ Request).CPCond2 is only asserted if a location is available in the Cell AddressBuffer. Therefore, if the APU 52 polls CPCond2 and finds that it istrue, it knows that a location is available in the Cell Address Buffer.By not clearing the Channel Group Credit Register 58b until after allmembers of the channel group have been serviced, the APU 52 can sensethe state of CPCond3 in between segmentation operations to insure that alocation is available in the Cell Address Holder before branching to thesegmentation routine.

If CPCond3 is not asserted at a time when the APU 52 knows that a bit isset in the Channel Group Credit Register 58b, the APU 52 knows thatCPCond2 is temporarily deasserted due to the fact that the Cell AddressFIFO is full. The APU 52 would then forgo the segmentation routine andcheck to see if there are any Received Cells in need of processing orexternal messaging requests that need to be resolved. In this fashionthe APU 52 manages to pace itself so that it does not allow thesegmentation process to get ahead of itself.

The Cell Address FIFO mentioned above is a two deep FIFO that holds theVCR 56 addresses of cells that are ready for transmission. When theTransmitter reaches the end of a cell, it checks the Cell Address FIFOto see if an address exists for a completed cell. If it does, the PCI'sTransmitter 62a will automatically begin fetching the new cell from theVCR 56 and sending it, one byte at a time, to the external transmissionconvergence framing logic over PCI₋₋ TxData(7:0). If an address does notexist in the Cell Address FIFO when the end of the present cell isreached, the Transmitter performs Cell Rate Decoupling.

3.6.1.3 Cell Rate Decoupling

As part of its start up code and prior to initiating Transmitteroperations, the APU 52 must build a complete "IDLE Cell" in the VCR 56and pass the address of the idle cell to the Transmitter by writing itinto the "IDLE Cell Address Register". The IDLE cell pattern should bethe same length as the user defined cell size. By designating an area inthe VCR 56 as the IDLE Cell Holder, a user is free to generate an IDLEcell that matches his switch specific structure.

During normal operation, if the ATMizer 50 reaches the end of thecurrent cell and no other address is available in the Cell Address FIFO,it will send the cell that resides in the VCR 56 location pointed to bethe IDLE Cell Address Register (most likely but not necessarily an "IDLEcell"). The ATMizer 50 will assert its PCI₋₋ IDLE output pin to informexternal logic that the cell it is transmitting is an IDLE cell. Pleaserefer to section 11 for detailed timing of PCI₋₋ IDLE assertion anddeassertion.

3.61.4 Preparing the Transmitter to Transmit

When the ATMizer 50 powers up, the contents of the VCR 56 and the IDLECell Address Register are both undefined. External logic must notattempt to clock data out of the ATMizer 50 before the ATMizer 50 hashad a chance to initialize at least the IDLE cell generation circuitry.As part of its reset routine, the APU 52 must create the IDLE cellpattern in the VCR 56 and set the IDLE Cell Address Register to point tothis cell structure.

Once the APU 52 has done this it can enable the Transmitter and initiatethe IDLE Cell generation process by setting the "Cells Available" bit inthe control register. As soon as the PCI Transmitter 62a sees the "CellsAvailable" bit set, it will begin fetching and transmitting the IDLEcell pattern. As soon as the APU 52 queues an assigned cell fortransmission by writing its start address into the Cell Address FIFO,the Transmitter will send the assigned cell after reaching the end ofthe current IDLE cell transmission.

External logic can abort the sending of a cell by asserting the PCI₋₋TxSync input. If PCI₋₋ TxSync is asserted prior to the APU 52 settingthe Cells Available bit, the Transmitter will not react to itsassertion. It will remain idle. If PCI₋₋ TxSync is asserted after theAPU 52 has generated the IDLE pattern and set the Cells Available bit,the Transmitter will react to the assertion of PCI₋₋ TxSync besuspending transmission of the existing cell and immediately beginningTransmission of a new cell. If there is an address available in the CellAddress FIFO, the PCI Transmitter 62a will begin fetching and sendingthe cell pointed to by that address. If no address is available then thePCI 62 will fetch and send the IDLE cell pattern.

A short period of time exists between the assertion of PCI₋₋ TxSync andthe Transmitter's ability to access the first byte of cell data from theVCR 56. External logic must be careful not to assert the dataacknowledgment (PCI₋₋ TxAck) input until the ATMizer 50 has successfullyretrieved the first byte of data from the VCR 56 and sourced it ontoPCI₋₋ TxData(7:0).

The ATMizer 50 indicates to the outside world that it has retrieved thefirst byte of data by asserting its DRDY output. After system reset ortransmitter synchronization, external logic must wait for the ATMizer 50to assert DRDY before proceeding (i.e. asserting PCI₋₋ TxAck). DRDY isdeasserted in response to either of the two reset events describedabove. Once DRDY is asserted it will remain asserted and data willcontinue to be sourced onto PCI₋₋ TxData(7:0) as long as PCI₋₋ TxClkremains within specification.

In addition to the IDLE and DRDY signals, the Transmitter asserts BOC(Beginning of Cell) each time it has placed the first byte of data for acell onto PCI₋₋ TxData(7:0).

3.6.2 Parallel Cell Interface Receiver 62b

The Receiver in the Parallel Cell Interface 62 is responsible foraccepting bytes of cell data from the ATM port side Receiver's PCI₋₋RcData(7:0) bus and using these bytes of data to reconstruct cells inthe VCR 56. The Receiver 62b is also responsible for informing the APU52 that a cell has arrived by triggering an internal "Received₋₋ Cell₋₋Indication" event.

Upon detecting the arrival of a cell, the APU 52 can read the cellheader and use it as an index into a VCR 56 based or memory based lookup table. From this look up the APU 52 determines the AAL type used forthe VC and the operation/s that must be performed on the cell. Theoptions are as follows:

3.6.2.1 Received Cell Handling Options

The received cell handling options in a dual port switch/terminationstation are illustrated in FIG. 17.

1. Reassembly: The APU 52 can choose to reassemble the cell into aCS-PDU in memory by initiating the appropriate DMA operations. In thecase of reassembly, the DMA controller 60 is configured with the VCR 56address of the SAR SDU, the memory address of the CS-PDU and theappropriate transfer length count. The DMA controller 60 thenautomatically accomplishes the reassembly operation through a series ofmemory write transfers.

2. Internal Switching: The ATMizer 50 is capable of transferring cellsthat arrive over the ATM port side Receiver out of the ATMizer 50utilizing the ATM port side Transmitter without ever passing the cellout to main memory. See section 2.8.1 for more information on internalswitching.

3. External Switching: In certain applications, the ATMizer 50 will wantto pass entire cells, headers and trailers intact, to some other ATMport interface that has access to the same memory space as the ATMizer50 (perhaps it is another ATMizer 50).

In such a situation, the ATMizer 50 may choose to first execute one ormore header manipulation operations before transferring the cell to thecentralized memory structure. After performing these operations, theATMizer 50 initiates a DMA operation to transfer the cell to memory sothat another ATM port interface can gain access to it. Aftertransferring the cell to memory the ATMizer 50 can alert another portinterface to the availability of the cell by asserting one or moreParallel Port 64 output pins or by writing to a memory mapped mailboxlocation.

4. Discard the Cell: The APU 52 can chose to discard the cell by writingto the Received Cell Counter without initiating any DMA operations. Ifthe APU 52 wishes to count IDLE cells, it can first increment the IDLEcell counter before proceeding. In addition, the APU 52 may wish toreact to CRC10 errors by simply discarding the cell.

3.6.2.2 Received Cell Indication. How the APU 52 Recognizes that Cellsare Awaiting Processing in the VCR 56.

A general signal timing diagram is illustrated in FIG. 18.

As mentioned above, once the ATM port side Receiver has reconstructed acell in the VCR 56, it indicates this to the APU 52 by asserting theinternal signal "Received₋₋ Cell₋₋ Indication". Received₋₋ Cell₋₋Indication is connected internally to the APU 52's CPCond1 input pin.

The APU 52 can check for the presence of received cells that have yet tobe processed by periodically polling CPCond1 using the "Branch onCPCond1 True" instruction. If the APU 52 senses that CPCond1 is set(i.e. a cell is available) it can then begin processing the cell. Thelogic in the PCI Receiver 62b that generates Received₋₋ Cell₋₋Indication is an up/down counter.

Each time a cell arrives the counter counts up by one. Each time thatthe APU 52 processes a cell it lowers the count by one by writing to aspecial location in the PCI 62 that causes the counter to count down.Therefore, if the APU 52 becomes occupied handling certain boundaryconditions or gets blocked from the memory backplane for a period oftime, cells will begin piling up in the VCR 56 and the Received CellCount will continue to rise.

Once the APU 52 frees up it should immediately begin draining theReceived Cell Buffer. Each time it processes a cell it reduces theReceived Cell Counter by one and then immediately checks to see ifadditional cells are in the VCR 56 by polling its CPCond1 input. IfCPCond1 remains asserted cells have accumulated in the Receiver andshould be drained before processing any pending segmentation requests.

Of course, the system designer may wish to interleave segmentationhandling in with Received Cell draining. This is acceptable but it doesprolong the period of time required to drain the Received Cell Bufferand increases the chance that a busy backplane will cause eventualReceived Cell Loss.

If the Receivers cell buffer overflows cells will no longer be writteninto the VCR 56 until a locations is freed up. The Overflow signal issent off chip as PCI₋₋ RcBuffover to inform the outside world of thiscondition. It is also attached internally to APU 52 interrupt five. IfAPU 52 interrupt five is enabled in the APU 52, the APU 52 willrecognize the interrupt, otherwise it will not be informed of thecondition.

3.6.3 HEC Generation and Checking

In applications that generate and check their own HEC values, ATMizer 50HEC generation can be disabled by asserting the HEC Disable bit in theSystem Control register. If a cell of size other than 52 bytes (53including the HEC) is used, internal HEC generation should be disabled.When HEC generation is enabled, the PCI₋₋ HECError pin is an output pinthat indicates whether an HEC error was detected on an incoming cell.

Cells arriving with HEC errors are discarded by the PCI Receiver 62b andexternal circuitry is informed by the assertion of PCI₋₋ HECError. IfHEC generation is disabled, no HEC checking will be performed.

When configured with HEC generation disabled, PCI₋₋ HECError acts as aninput pin. External logic can prevent the ATMizer 50 from writing acorrupted cell into the VCR 56 by asserting PCI₋₋ HECError whileproviding the first byte of the SAR PDU to the Receiver. External logicshould not suspend cell transfer to the ATMizer 50 when an HEC error isencountered. It should continue with cell transfer but simply inform theATMizer 50 to discard the cell by asserting PCI₋₋ HECError.

3.6.4 External Buffering of Received Cells

The PCI Receiver 62b supplies a signal that can be used by externallogic to prebuffer received cells. The PCI₋₋ RcBuffHalf output indicatesto the Transmission Convergence framing logic that the internal ReceivedCell Holder buffer in the VCR 56 has reached or exceed one half full.External logic can use this signal to switch cell buffering over to an×K×8 SRAM buffer.

This buffer would be a dual port buffer that logically had a read portand a write port. IDLE cells would be filtered before entering thisbuffer. Once the APU 52 has processed a number of cells in the VCR 56and PCI₋₋ RcBuffHalf is deasserted, external logic could begintransferring the cells queued up in the external SRAM into the ATMizer50 for processing (maintaining FIFO sequentiality).

3.6.5 Frequency Decoupling

The ATMizer 50 contains all of the logic necessary for decoupling theATMizer 50's internal clock (i.e. the system clock) from the clock ratesof the transmission lines. The user clocks byte wide data out of theATMizer 50 relative to the byte clock that is used to drive thetransmission line and clocks data into the ATMizer 50 relative to thebyte clock derived from the received data stream.

All frequency decoupling and metastability issues are dealt with insidethe ATMizer 50's Parallel Cell Interface 62 circuitry. The ATMizer 50uses a simple handshake acknowledgment mechanism to allow external logicpause data transfers between the ATMizer 50 and the line transceivers.Such a stall may be required if external logic suspends the cell streamin order to generate and send or extract transmission convergence layerframing overhead. Much more can be found on this interface in section11.0.

3.7 Parallel Port 64

The ATMizer 50 includes an eight bit Parallel Port 64 that can be usedto accomplish a variety of data transfer and control transfer operationsbetween the APU 52 and the outside world. Parallel Port 64 accessdiffers from DMA access in the following fashion:

1. The Parallel Port 64 can be read and written by the APU 52 directly,utilizing Load Byte and Store Byte instructions. The DMA controller 60allows only indirect APU 52 access to memory mapped devices (the APU 52programs the DMAC 60 to transfer data between the VCR 56 and memorymapped devices).

2. The Parallel Port 64 is also unique in that it can be accessed by theAPU 52 when the DMA engine is busy. In this fashion the parallel portgives the APU 52 an ability to control DMA operations simultaneously tothe operation. This may be of use in switching applications if the APU52 wishes to notify another switching port that it is about to source acell targeted to it onto the memory backplane.

3. The Parallel Port 64 can also be used to control physical devices bymapping certain Parallel Port 64 data bits to certain hardwarefunctions.

4. The Parallel Port 64 can also be used in the ATMizer <-> Hostmessaging system. The Host processor can pass a message to the ATMizer50 by writing an 8 bit message code to a parallel port mapped registerand then asserting ATMizer 50₋₋ Int. The APU 52, polling ATMizer₋₋ Int,branches to the messaging routine, reads in the register and takes theappropriate action based on the message code retrieved. Or, the ATMizer50 can simply poll certain control information from the Parallel Port64.

The Parallel Port 64 has a one deep write buffer in it. Writes to theParallel Port 64 when the write buffer is empty will not stall the APU52. Writes to the Parallel Port 64 when the write buffer is full willresult in the APU 52 stalling until the write in the write buffer isretired to memory. The APU 52 will stall when reading the Parallel Port64 if the Parallel Port 64's write buffer is full or if externalhardware prolongs the read operation by withholding assertion of PP₋₋RdWrAck.

In addition to 8 data bits, Parallel Port 64 accesses provide 4 addressbits to distinguish between up to 16 external devices. The Parallel Port64 sources the address bits transferred over CPUAddress(5:2) during APU52 Load or Store operations that target the Parallel Port 64.

4.0 The System Control Register

Certain functions within the ATMizer 50 are programmable and must beconfigured at system reset time. All ATMizer 50 configurationinformation is stored in the System Control Register that is written bythe APU 52 as part of its initialization routine. The System ControlRegister is programmed using a Store Word instruction. CPUData(31:0) iswritten into the fields of the System Control Register as illustrated inFIG. 19.

BUFFER SIZE

Buffer Size determines the size of the Received Cell Holder Buffer.Received cells are written into the VCR 56, one per 64 byte block,starting at location 0. The high order address is determined by theBuffer Size field.

    ______________________________________                                        CR - CELLS READY                                                              ______________________________________                                        0001 Buffer Size = 2                                                                             0100 Buffer Size = 8                                       0010 Buffer Size = 4                                                                             1000 Buffer Size = 16                                      ______________________________________                                    

CR--CELLS READY

The APU 52 sets the Cells Ready bit once it has configured the SystemControl Register, built an IDLE cell in the VCR 56 and passed a pointerto the IDLE cell to the IDLE cell address holder in the PCI Transmitter62a. The PCI Transmitter 62a will not attempt to source any cell dataonto its output bus until Cells Ready is asserted. Once asserted, thePCI Transmitter 62a fetches a cell (either the IDLE cell or an assignedcell if the APU 52 writes a cell address into the Cell Address FIFObefore setting Cells Ready) from the VCR 56 and sources it over PCI₋₋TxData(7:0).

DH--DISABLE HEC GENERATION AND CHECKING

In applications that generate and check their own HEC values, ATMizer 50HEC generation can be disabled by asserting the HEC Disable bit in thesystem control register. If a cell of size other than 52 bytes (53including the HEC) is used, internal HEC generation should be disabled.When HEC generation is enabled, the PCI₋₋ HECError pin is an output pinthat indicates whether an HEC error was detected on an incoming cell.

Cells arriving with HEC errors are discarded by the PCI Receiver 62b andexternal circuitry is informed by the assertion of PCI₋₋ HECError. IfHEC generation is disabled, no HEC checking will be performed.

When configured with HEC generation disabled, PCI₋₋ HECError acts as aninput pin. External logic can prevent the ATMizer 50 from writing acorrupted cell into the VCR 56 by asserting PCI₋₋ HECError whileproviding the first byte of the SAR PDU to the Receiver. External logicshould not suspend cell transfer to the ATMizer 50 when an HEC error isencountered. It should continue with cell transfer but simply inform theATMizer 50 to discard the cell by asserting PCI₋₋ HECError.

CTR 4/5--COUNTER 4/5

When CTR 4/5 is set, PRPCs 4 and 5 are tied together into a 24 bittimer/counter. PRPC 4 forms the low order 12 bits of the timer/counterand PRPC 5 forms the high order 12 bits of the timer/counter.

CTR 6/7--COUNTER 6/7

When CTR 6/7 is set, PRPCs 6 and 7 are tied together into a 24 bittimer/counter. PRPC 6 forms the low order 12 bits of the timer/counterand PRPC 7 forms the high order 12 bits of the timer/counter.

CELL SIZE

The ATMizer 50 supports a user defined cell size from 52 bytes up to 64bytes. The actual cell size to be used is programmed into the Cell Sizefield by the APU 52 during system reset. The APU 52 must program CellSize before setting the Cells Ready bit.

5.0ATMizer 50 Memory Map

A map of the memory of the ATMizer 50 is illustrated in FIG. 20.

Except where noted below under VCR 56 Notes (Load w/DMA BusyConsiderations, Type 1 and 2 Instructions) and under DMA Notes (DMAOperation Initialization instruction), all internal access should beinitiated with CPUAddress(31:20) set to 0s.

VCR 56 NOTES

If Address Bit 22 is set during a VCR 56 Read Operation we are executinga "Load with DMA Busy Considerations, Type 1" instruction and the APU 52will stall if the first word of the DMA operation has not been retiredto the VCR 56.

If Address Bit 23 is set during a VCR 56 Read Operation we are executinga "Load with DMA Busy Considerations, Type 2" instruction and the APU 52will stall if the DMA operation has not completed.

    __________________________________________________________________________    DMAC NOTES                                                                    CPUAddress(31:30)   Local Offset Register                                     CPUAddress(29:24)   Transfer Length Counter                                   CPUAddress(21)      Ghost Bit                                                 CPUAddress(20)      Operation Direction (Rd Vs Wr)                            CPUAddress(11:2)    LocalAddress Counter                                      CPUData(31:0)       Memory Address Register/Memory                            Address Counter/Memory Offset Register                                        PRU NOTES                                                                     RRR                                                                              PRPC                                                                              RRR                                                                              PRPC                                                                              RRR PRPC                                                                              RRR PRPC                                                000                                                                              PRPC0  010 PRPC2   100 PRPC4                                                                             110                                                                              PRPC6                                        001                                                                              PRPC1  011 PRPC3   101 PRPC5                                                                             111                                                                              PRPC7                                        BBB                                                                              CRB BBB                                                                              CRB BBB CRB BBB CRB                                                 000                                                                              Bit0                                                                              010                                                                              Bit2                                                                              100 Bit4                                                                              110 Bit6                                                001                                                                              Bit1                                                                              011                                                                              Bit3                                                                              101 Bit5                                                                              111 Bit7                                                __________________________________________________________________________

The RRR field determines which of the eight Peak Rate Pacing CounterInitialization Registers are the target of the write operation.

The BBB field determines which bit of the Credit Register 58b istargeted for being cleared. A write to the Credit Register 58b clearsthe Credit Bit associated with the PRPC 58a addressed by the BBB field.Reading the Credit Register 58b returns the 8 bit Credit Register 58bValue on Data Bits (7:0). The BBB field is ignored on reads.

If the I bit is set to 1 the Initialization value is immediately writteninto both the Initialization register and the Peak Rate Pacing Counter58a, overwriting the values in each of these structures. If the I bit isset to 0, the Initialization register is written but the counter 58a isallowed to continue with its count. Once the count reaches zero, the newinitialization value will be written into the Peak Rate Pacing Counter58a.

PCI NOTES

When the PCI 62 Address FIFO is written, the value of the CCC field (thecommand field) is used to determine what actions the transmitter shouldtake in regards to the cell being queued for transmission. If bit 9 isset, the Transmitter will Force an HEC Error (HEC generation must beenabled). If bit 8 is set, the Transmitter will calculate and insert a10 bit CRC10 value for this cell.

In this fashion, the ATMizer 50 can support AALs 1, 2, 3/4 and 5simultaneously because a CRC10 is only generated by the PCI 62 when itis instructed to do so by the processor. If bit 7 is set, theTransmitter will force an error in the CRC10 encoding (Big 8 must be setas well).

The CRC10 error register is a 16 bit register that contains one bit foreach Received Cell Holder. If a CRC10 error is detected for a cell inthe corresponding received cell holder, the corresponding CRC10 errorregister bit is set.

If a VC is determined to be an AAL 2 or AAL 3/4 VC, the APU 52 mustcheck the CRC10 error register for an indication of a CRC10 error. Ifthe VC is determined to be an AAL 1 or AAL 5 VC, the APU 52 will notcheck the CRC10 error bit for that Received Cell Holder. In this fashionthe ATMizer 50 can support simultaneously, cells of all AAL types.

Parallel Port 64 NOTES

The address indicated in the four bit field marked AAAA is sourced ontoPP₋₋ Address(3:0) during parallel port read and parallel port writeoperations.

6.0 The ATMizer 50's Interrupt Structure and CpCond Hookups

INTERRUPT STRUCTURE

The R3000 CPU has six interrupt inputs. Each of these interrupts can beenabled or disabled by software running on the APU 52 (see MIPS assemblylanguage programmer's guide). The ATMizer 50 uses all six of the APU52's interrupt pins for a variety of purposes. User firmware may choseto enable and use any of these interrupts or may instead chose not toimplement interrupts and interrupt handling.

    ______________________________________                                        Interrupt 1 Counter/Timer 4/5 time-out (only asserted                         if          PRPC4/5 configured as counter/timer)                              Interrupt 2 Counter/Timer 6/7 time-out (Only asserted                         if          PRPC 6/7 configured as counter/timer)                             Interrupt 3 General Purpose External Interrupt 1                              Interrupt 4 General Purpose External Interrupt 2                              Interrupt 5 Received Cell Buffer Overflow                                     Interrupt 6 Received Cell Buffer Half Full                                    ______________________________________                                    

CPCOND CONNECTIONS

The APU 52 can check the state of any one of the CpCond inputs byexecuting a "Branch on Coprocessor x Condition Input True/False"instruction. ATMizer₋₋ Int differs from GP₋₋ Int1 and GP₋₋ Int2 in thatit is not an interrupt in the lassic sense but simply a signal whosestate can be tested when so desired by the APU 52 by issuing the "Branchon CPCond0 True/False" instruction.

CPCond0 Connected to ATMizer 50₋₋ Int external pin

CPCond1 Connected to Receive Cell Indication

CPCond2 Connected to PRU's Transmit Request Output (i.e CGCR 58b has abit set)

CPCond3 Connected to DMA₋₋ Rqst

7.0 Programming the ATMizer 50

No two ATMizer 50 applications are likely to be identical, and thereforeeach system designer will create APU 52 firmware specifically tailoredto his system implementation. In general though, it can be shown thatthe basic firmware routine will revolve around the IDLE loop illustratedin FIG. 21 which checks for the existence of one of three conditions andtakes the appropriate actions if one of the states exists.

The order in which the CpCondx pins are tested in our sample IDLEroutine is significant. In our sample system we always check forReceived Cell Indication first. The reason for this is that it is moreimportant not to drop a received cell (if the received cell bufferoverflows) than it is to prevent an IDLE cell from being transmitted.

    ______________________________________                                        IDLE                                                                          BCP1 True Receive Cell                                                                       If RcInd is asserted jump to the                               receive        cell routine                                                   LDW R8 R24     Load in the ATM Header of the                                  received cell                                                                 BCP0 True Message                                                                            If ATMizer 50.sub.-- Int is asserted                           jump to the message routine                                                   NOP                                                                           BCP2 True Transmit Cell                                                                      If TXReq is asserted jurnp to the                              transmit cell routine                                                         LW R1, PRUCB(R0)                                                                             Get the eight bit CGCR (Channel                                Group Credit Register)                                                                       58b value representing which                                   channel banks have expired                                                    ______________________________________                                    

Therefore, we always check for received cell indication before checkingfor either a Host messaging request or a transmit cell request.Furthermore, because the ATMizer 50 can be asked to accomplish certaincomplex functions, the possibility exists that the servicing of either areceived cell indication, transmit cell request or message request couldtake longer than the time normally allotted in steady state operation(approximately 65 instructions for transmit cell requests and receivedcell processing at 50 MHz). As a result, cells may accumulate in the VCR56 and firmware may wish to always drain this buffer before occupyingthe memory backplane with segmentation data transfers. 8.0 ATMizer <->Host Messaging

The ATMizer 50 is further capable of messaging with a host in a mannerwhich can be programmed into the system firmware.

9.0 The ATMizer in Operation

A diagram of the ATMizer 50 in a system supporting AAL 1 and AAL 5circuit termination and cell switching is illustrated in FIG. 22.

9.1 Data Types Supported

The ATMizer 50 is capable of handling a combination of data types from avariety of data sources. In general, if the necessary data and controlinformation (i.e. the Residual Time Stamp values for AAL1 connections)can be accessed by the ATMizer 50 from a memory mapped entity (eitherRAM or a peripheral interface controller) the ATMizer 50 can create anATM cell or cell stream from the data source.

This applies to real-time data stream sources such as DS1 linetermination as well as to packet generating sources such asworkstations, packet-based LANs and WAN interfaces. This also applies tothe switching of ATM cells to and from other ATM ports or switchingfabrics as long as the switching fabric is mapped into the ATMizer 50'sDMA memory space or accessible over the ATMizer 50's Parallel Port 64interface.

9.2 The Cell Generation Process--An Overview

It is important to understand that almost all aspects of the cellgeneration process are controlled by the ATM Processing Unit (APU) 52under user firmware control. To accomplish segmentation, the APU 52functions as an event driven device. A segmentation triggering event canbe an external event such as the filling of a DS1 buffer or an internalevent such as the timing out of one of the eight on-chip Peak RatePacing Counters (PRPCs) 58a.

The APU 52 learns about external events by periodically polling a DMAmemory mapped or Parallel Port 64 memory mapped register that has a bitassociated with each external triggering event or by polling itsATMizer₋₋ Int signal for an indication that an external event hasoccurred. Polling ATMizer₋₋ Int is a faster mechanism because its statecan be tested with a single APU 52 instruction (Branch on CoprocessorCondition 0 True).

However, since ATMizer₋₋ Int is expected to be used as part of thehost-to-ATMizer messaging system, the assertion of ATMizer₋₋ Int mayhave to be qualified by access to a "message type" field or registersomewhere in DMA or Parallel Port 64 memory space. This field indicatesthe reason for which external logic asserted ATMizer₋₋ Int. In ourexample, the value would indicate that ATMizer₋₋ Int was asserted toalert the ATMizer 50 to a DS1 buffer full condition.

An internal triggering event most likely consists of the time-out of oneor more Peak Rate Pacing Counters 58a. In general, internal events areused to pace the segmentation of CS-PDUs while external events are usedto pace cell generation from real time data streams.

When one or more counters 58a times-out the Pacing Rate Unit 58 respondsby asserting the Coprocessor Condition 2 (CpCond2) input to the APU 52.The APU 52 frequently checks the state of this input by executing asingle Branch on Coprocessor Condition 2 True instruction. If the APU 52senses CpCond2 asserted it branches to the Segmentation routine andreads in an 8 bit value from the CGCR 58b that indicates which countershave expired.

The APU 52 can then proceed to segment the CS-PDUs associated with thePeak Rate Pacing Counter/s 58a that have expired. Since the APU 52 canread the CGCR 58b at any time, even in the midst of servicing a ChannelGroup, the User is able to implement almost any channel priority schemethat fits the application.

9.2.1 AAL 1 Real-Time Data Streams

The ATMizer 50 is capable of generating AAL 1 SAR--PDUs from memorymapped data buffers. In most cases, data streams such as DS1 lines willbe terminated and synchronized to the ATMizer 50's system clock thenpre--buffered in dual 48 byte buffers in main memory.

Once a buffer fills, the ATMizer 50 can be instructed (through anexternal event) to retrieve the SAR User Payload, retrieve (RTS) orgenerate (SN/SNP) and append the SAR Header and transfer the cell to thetransmission convergence framing logic using the Transmitter 62a in theATMizer 50's Parallel Cell Interface 62.

As the ATMizer 50 is generating a cell from one buffer the other bufferis being refilled by the real-time data source. Eventually the secondbuffer will fill and the first buffer will become the active fillbuffer. ALL 1 data streams are continuous in time. The APU 52 under userfirmware control creates the Sequence Number and Sequence NumberProtection fields internally but is passed the Residual Time Stamp fieldfrom an external device.

Residual Time Stamp values can be passed to the ATMizer 50 in byte 0 ofthe SAR SDU (the logical positioning, in this case external logiccalculates the RTS and writes it into the data buffer) or the APU 52 canproactively retrieve the RTS value, when needed, utilizing either theParallel Port 64 or DMA Engine.

The APU 52 is responsible for implementing RTS and SN/SNP interleavingon transmission and for passing the SAR SDUs and RTS values to theappropriate buffers and interfaces and SN/SNP checking on reassembly.The actual AAL1 cell generation and received cell handling routinesshall be written by the user.

FIG. 23 illustrates AAL1 circuit emulation and data buffering asperformed by the ATMizer 50, whereas FIGS. 24 and 25 illustrate AAL 5CD-PDU segmentation.

In situations where DS1s are to be sourced over an ATM port, the lowdata rates of the DS1s allow for multiple such lines to be handled withease. In low speed applications, the ATMizer 50 itself can be programmedto handle the transfer of data from a small word buffer in the DS1physical interface device to the dual 48 byte buffers in main memory.

In some applications the VCR 56 itself could provide the dual databuffer functionality. Using the ATMizer 50 in this fashion alleviatesthe need for intelligent DMA operations at the DS1-main memory interfaceand simplifies memory controller design.

Since the overhead on the ATMizer 50 to facilitate these transfers isquite high, such "dumb" DS1 ports may only be usable at ATM port speedsat or below DS3 rates. It is up to the user to make a finaldetermination if a chosen implementation can sustain the desiredthroughput rates.

9.2.2 AAL 3/4 and 5 CS-PDUs Segmentation

AAL 5 CS-PDU Segmentation is illustrated in FIGS. 24 and 25.

If an internal event occurs (a PRPC 58a has expired forcing theassertion of CpCond2), the APU 52 determines which PRPC/expired byreading the Channel Group Credit Register 58b. The APU 52 then begins toparse through the list of Channel Parameter Entries that are attached tothe expired PRPC 58a segmenting a number of cells from each CS-PDUbefore proceeding on to the next entry in the Channel Group (this is allby software design, the ATMizer 50 is APU 52 driven and differentconcepts of how segmentation should be controlled are both imaginableand supportable).

As the APU 52 parses through the Channel Parameter Entries in theChannel Group, it can generate one or more cells from a given CS-PDUbefore proceeding on to the next Channel Parameter Entry in the list.Again, depending on the application this list will either be VCR 56resident or main memory resident with the tradeoff being that VCR 56resident lists have limits on their sizes (i.e. a limit on the number ofchannels that can be active simultaneously) but allow for less costlymemory system implementations while memory based lists have fewrestrictions on their size but may require fast SRAM to support theprocessors need for fast access to the entry (as well as fast access torestore the updated entry to memory at the end of the segmentation/cellgeneration burst for each Channel Parameter Entry/CS-PDU).

CONTIGUOUS CS-PDUS

In the most straight-forward of system implementations, AAL 3/4 and 5CS-PDUs are created in system memory by a host processor. The ATMizer50's job is to segment these CS-PDUs into a series of SAR-SDUs, generateand append ATM Adaptation Layer headers and trailers and ATM headers tothe SAR-SDUs and then transfer the newly built cells to the externalTransmission Convergence Sublayer framing logic one byte at a time usingthe Transmitter portion of the ATMizer 50's Parallel Cell Interface(PCI) 62.

CS-PDUs undergoing segmentation will be resident and contiguous insystem memory prior to the ATMizer 50 beginning the segmentationprocess. In addition to performing segmentation and ATM cell generation,the ATMizer 50 will also calculate the CRC32 for AAL 5 CS-PDUs andappend the resulting 4 bytes of CRC32 code to the end (bytes 50-53) ofthe last cell generated from the given AAL 5 CS-PDU. The host processorconstructs the entire AAL 3/4 or 5 CS-PDU in system memory but, in thecase of AAL 5, should stuff all zeros into the last four bytes (theCRC32 field).

NON-CONTIGUOUS CS-PDUS--THE "GATHER" FUNCTION OF SCATTER-GATHER DMA

In more complicated system environments, CS-PDUs may be resident inmemory in a non-contiguous fashion. This may occur in ATM networkinterface card applications if the operating system builds higher layerheader fields apart from the actual "User Payload" portion of the packetor if headers from different layers are created physically separatethough logically belonging to the same CS-PDU.

It may also occur if the User Payload field consumes more than one pagein a virtual memory system and memory management software allocatesnon-contiguous pages to the application. Forced moves to create acontiguous CS-PDU are wasteful of system resources and time.Fortunately, such moves are unnecessary in systems employing the ATMizer50.

In routing applications (or CSU/DSU applications), the system designermay wish to provide for the segmentation of packets (CS-SDUs) prior totheir complete arrival. Segmenting a CS-SDU as it arrives reduces theamount of buffer memory required in the bridging mechanism. It alsoreduces the latency attributable to the router. In applicationsemploying ATM Adaptation Layer 5, the ATMizer 50 can begin packetsegmentation as soon as enough bytes arrive for the host processor toestablish the route and before the host processor has built the CS-PDUtrailer.

In addition, the memory allocation mechanism of the router may allocatememory to incoming packets in blocks of size less than the maximumpacket size (these blocks are referred to as memory "fragments"). Thisis useful in applications where packet sizes can vary dramatically.Small packets may take up a single memory "fragment" while much largerpackets may require the allocations of several "fragments".

The ATMizer 50 proceeds through the segmentation process "one fragmentat a time"; communicating with the host processor or accessing a linklist of the CS-PDU from system memory as fragment boundaries arereached.

In "Gather" applications, the APU 52 will periodically reach the end ofa particular CS-PDU fragment. The APU 52 must be able to determine if ithas reached the end of a fragment or if it has actually reached the endof the CS-PDU. This information is needed to insure that the APU 52 doesnot prematurely insert an EOM (or SSM) identifier into the SAR Headersof AAL 2 and 3/4 cells or encode an EOM identifier into the PTI fieldsof the ATM Headers of AAL 5 cells.

Therefore, it is important that a flag field be included in the ChannelParameter Entry that indicates whether the fragment represents the endof a CS-PDU or if more fragments exist for the CS-PDU. Software runningon the APU 52 must check this condition during the segmentation process.

Since the APU 52 must check the resulting byte count each time itdecrements it, it is possible to signal end-of-CS-PDU by providing abyte count in the Channel Parameter Entry that will reach exactly zeroat the end of a fragment that represents the end of the CS-PDU and onethat will produce a negative result for fragments that are not the lastfragment (i.e. the byte count would by at least 1 byte less than theactual count). These and other techniques can be employed todramatically reduce the number of APU 52 instructions required togenerate (or process) a cell and shall be expanded upon later in thesection on programming the APU 52.

As mentioned previously, the APU 52 may chose to generate more than onecell from a given CS-PDU before proceeding on to the next CS-PDU. Thisis up to the user but it is important to understand that generatingmultiple cells per CS-PDU reduces the number of APU 52 cycles requiredto build a cell, and the APU 52 cycles required to retrieve and restorethe Channel Parameter Entry for the CS-PDU can be amortized over thenumber of cells generated. This may be important in high speedapplications (155 mbps), especially if a large number of simultaneouslyactive Transmit channels are to be supported.

Once the cell generation routine has been entered, cell generationinvolves the APU 52 retrieving a Channel Parameter Entry (from the VCR56 or off chip), using the DMA Address to initiate a memory Readoperation to retrieve the SAR SDU (size dependent on AAL type and on"Gather" algorithm employed), retrieving the ATM Header from the ChannelParameter Entry, modifying certain fields (GFC, PTI, CLP) if necessaryand writing the Header into the appropriate location in the VCR 56 (justin front of where the DMA Controller 60 was instructed to write the SARSDU).

If the cells are AAL 3/4 cells, the APU 52 must also retrieve theprevious SAR Header and use it (i.e. the previous sequence number) togenerate the current SAR Header. The APU 52 must also set the LI fieldin the VCR 56 (by writing it to the tail end of where the DMA Controller60 was instructed to write the SAR SDU after the SAR SDU retrieval hascompleted since the DMAC does not clip VCR 56 or memory write operationson the tail end of the last word) and finally by queuing the cell fortransmission by writing its VCR 56 address into the Cell Address FIFO inthe PCI Transmitter 62a.

AAL 5 cells do not require SAR Header or Trailer generation operationsbut they do require CRC32 partial results maintenance and CRC32insertion into the last cell of a CS-PDU.

The number of actual scenarios are too many to explore in detail in thisspecification (Scatter-Gather implementations, data alignment forapplication acceleration, user defined parsing and messaging routines,congestion control, statistics gathering, Interleaving of Segmentation,Reassembly and Messaging in the most effective manner, etc.). Thepresent invention is therefore not limited to the specific examplespresented herein, but is capable of numerous modifications andapplications within the scope of the disclosure.

A Cell Generation Data Path is illustrated in FIG. 26. As a overview ofthe segmentation process, CS-PDUs undergoing segmentation reside insystem memory. SAR-SDUs are retrieved from memory (AAL 5 SAR-SDU=48bytes, AAL 1 SAR-SDU=47 bytes) and placed in a Tx Cell Buffer in the VCR56. SAR and ATM Headers are appended by the APU 52 and then the cell isqueued for transmission over the Parallel Cell Interface 62.

An eight byte Elastic Buffer (Tx Buff) in the PCI 62 sits between theVCR 56 and the line driver. Data is fetched from the VCR 56 Tx CellBuffer relative to the ATMizer 50's system clock (Clk) but transferredout of the eight byte deep Elastic Buffer (Tx Buff) relative to theline's byte clock (PCI₋₋ TxClk).

CS-PDUs undergoing reassembly also reside in system memory. Data fromthe Receiver is temporarily buffered in a second 8 byte deep ElasticBuffer (Rc Buff). This buffered data is then transferred to the ReceiveCall Buffers in the VCR 56. The combination of elastic buffering andcell buffering provides all of the buffering needed in manyapplications.

9.3 The CS-PDU Reassembly Process

In addition to segmentation, the ATMizer 50 performs reassemblyoperations on AAL 3/4 and 5 CS-PDUs and AAL 1 real-time data streams. Inthe case of AAL 5 CS-PDUs, reassembly is the process of reconstructingCS-PDUs in system memory from a stream of cells received over theATMizer 50's ATM port interface. Of course, this stream of cells willcontain SAR-PDUs from a number of VCs/CS--PDUs simultaneously and theATMizer 50 will have to track operations on a number of active CS-PDUs.

The exact number of open VCs that the ATMizer 50 can support isimplementation dependent. By restricting the number of active channelsand caching all channel parameters in the on-chip VCR 56, low costnetwork interface cards can be built that use system memory for CS-PDUstorage, alleviating the need for dedicated memory on the NIC itself.

In higher speed applications, a larger number of channels (up to 65,536)can be supported through the provision of off-chip local DRAM and/orSRAM. In such implementations, the ATMizer 50 will go off chip to obtainthe Channel Parameter Entries necessary for CS-PDU reassembly. Of coursenot all high speed (155 mbps) applications will support very largenumbers of VCs. For example, an implementation of an ATM backbone maychoose to encapsulate all traffic from a single network under a singleVC/VP.

At the destination ATM switching point, the Convergence Sublayer stripsout the ATM encapsulation information exposing a diverse stream ofhigher layer packets. In such systems, these high speed ATM interfacedevices may wish to support only a limited number of networksegments/VCs (64-128) and as a result all channel parameters can becached inside the ATMizer 50 and local memory could consist solely ofDRAM.

As can be seen, the addition of on-chip memory allows ATMizer 50 usersto make several tradeoffs between system cost (local memory vs. no localmemory, DRAM vs. SRAM), ATM data rates and the number of channelssupported.

THE "SCATTER" FUNCTION

When the first cell of a CS-PDU arrives over the ATMizer 50's ATM portinterface, a buffer must be set aside in memory for reassembly. Becausethe ATMizer 50 is capable of "scatter" operations and buffer management,it is possible to allocate buffer space one block at a time. The ATMizer50 can then construct a link list of the buffers used during thereassembly process, requesting additional buffer allocations as theCS-PDU extends beyond the bounds of the existing buffers.

With AAL 3/4 CS-PDUs, an intelligent decision can be made up frontconcerning buffer allocation since AAL 3/4 CS-PDUs contain a CS-PDUlength indicator in their headers. But with AAL 5 CS-PDUs, size can notbe determined until the last cell of the CS-PDU has arrived. Without a"scatter" capability the system would be forced to allocate the maximumsize buffer to each new AAL 5 CS-PDU. This could put a severe strain onmemory resources if many channels are active simultaneously.

With "scatter" control, the granularity of buffer allocations can be assmall as the designer wishes. User firmware running on the ATMizer 50 isresponsible for retrieving available buffer lists, constructing linklists for the CS-PDUs during reassembly, and passing these lists orpointers to these lists to the host processor upon completion of thereassembly process (or perhaps the pointer to the next buffer is simplyappended to the present buffer).

It is important to note that the ATMizer 50 by design does not enforce ascatter architecture. The ATMizer 50 simply provides the resources toimplement the scatter function--the APU 52 and DMA Engines andATMizer--Host messaging capabilities. User firmware, downloaded to theATMizer 50 at system reset time, implements the buffer allocation andlink list pointer management processes chosen by the system designers asthe best mechanism for their application.

HEC ERROR, AAL 3/4 CRC10 ERROR AND AAL 5 CRC32 ERROR CHECKING

If HEC generation is enabled, the ATMizer 50 will automatically checkfor HEC errors and discard cells that are found to have HEC Errors (itwill also assert PCI₋₋ HECError). If HEC generation is enabled theATMizer 50 will also automatically discard IDLE cells. Therefore, thereassembly routines need not check for either condition.

If AAL 3/4 cells are to be supported, the reassembly routine will haveto check the CRC10 error register for an indication of CRC10 errors. Ofcourse, if the Channel Parameter Entry for a VC indicates that the cellis encoded using AAL 1 or 5, no CRC10 error checking should be employed.AAL 5 CRC32 checking is explained in detail in the section on the DMAC60.

10.0 Congestion Notification and Handling

Switching nodes within an ATM network that are experiencing congestioncan inform ATM end stations by modifying the ATM headers of ATM cellspassing through them. An end station receiving marked cells may takecorrective action. During reassembly, the APU 52 can search each cellheader for notification of congestion.

If congestion is found to exist, the APU 52 can execute whatevercongestion handling algorithm the system designer has chosen toimplement. There are several steps that the ATMizer 50's APU 52 can takein reaction to congestion notification.

1. The APU 52 can inform host software of the congestion problem buttake no additional action. Host software can react as it sees fit bylowering Average and Peak segmentation rates or Burst Lengths for one ormore CS-PDUs/VCs.

2. The APU 52 can react by increasing the service intervals for one ormore Channel Groups (increase the initialization values in one or morePRPCs).

3. The APU 52 can lower the Global Pacing Rate for the overallTransmission pipe.

4. The APU 52 can choose to selectively lower the CLP value for one ormore VCs. For real time sensitive data streams, CLP reduction may bepreferable to throttling the VC. These and other actions can be takenseparately or together to achieve the ultimate congestion handlingmechanism.

It is important to note that no congestion control algorithm is enforcedby hardware convention. Software running on the ATMizer 50 isresponsible for checking for congestion and implementing a user designcongestion control routine if congestion notification is found.

In actuality, the best congestion control algorithms may not be fullyunderstood until enough equipment is fielded to put real life demands onATM based networks. Much of that existing equipment may not be able tobe updated to deal with actual congestion problems.

Systems employing the ATMizer 50 don't have the same problems. Becauseit is programmable, the ATMizer 50 can execute virtually any congestioncontrol algorithm. Because its firmware is downloaded at system resettime, software "patches" can be sent out to existing customer sites withnew congestion algorithms for the ATMizer 50 when more is learned aboutactual network congestion. Because the APU 52 sits directly at the lineinterface, the ATMizer 50 can react quickly, within a single cell time,to congestion notification found on an incoming cell. And because it hasaccess to the Peak Pacing Rate registers 58a, Maximum Burst Lengthvalues, Global Pacing Rate Register 58c and the CLP fields in the ATMheaders, the ATMizer 50 has unlimited flexibility in its means forimplementing congestion control.

11.0 ATMizer 50 Pins

11.1 ATMizer 50 Pin Diagram

A pin diagram of the ATMizer 50 is illustrated in FIG. 27.

11.2 ATMizer 50 Signal List

DMA MEMORY INTERFACE

TERMINOLOGY

The "DMA Engine" is that function within the ATMizer 50 that handlesmemory transactions. The DMA Engine manages the functions of main andlocal (VCR 56) memory address incrementing, byte count reduction, andbyte alignments and mergers for transactions where the local bytestarting offset which is not equal to the memory byte starting offset.

A DMA "operation" is initiated by the APU 52. To initiate a DMAoperation, the APU 52 accesses the DMA Engine and sets the memorystarting address (byte address), the number of bytes in the transaction(<=64 bytes), the local VCR 56 starting address (byte address) and thedirection of the operation (Rd/Wr). The DMA Engine responds by assertingDMA₋₋ Rqst and by cycling through the required number of data"transfers" to complete the operation.

Devices accessed during DMA operations are responsible for informing theDMA Engine that the sourced data has been retired (on DMA Writetransfers) or that the requested data is available (on DMA Readtransfers) External devices (memory included) use the DMA₋₋ RdWrAcksignal to signal these transfer "acknowledgments". The DMA Engine can beidled indefinitely by the withholding of an expected acknowledgment.

SIGNALS

DMA₋₋ Rqst

DMA Operation Request--Output--Asserted High

Asserted by the ATMizer 50's DMA Engine when the APU 52 has programmedthe DMA Engine to execute a partial word, word or block transfer to orfrom a memory mapped device such as main memory. The accessed deviceshall respond to DMA₋₋ Rqst by asserting DMA₋₋ RdWrAck one or moretimes.

The ATMizer 50 does not have a specific DMA Grant input. External logiccontrols ATMizer 50 bus access with DMA₋₋ AdrOEx, DMA₋₋ DataOEx andDMA₋₋ RdWrAck. DMA₋₋ Rqst will be removed following the rising clockedge upon which the ATMizer 50 samples the final transfer acknowledgment(DMA₋₋ RdWrAck asserted) for the given DMA operation.

If the APU 52 has queued up back to back DMA operations (it may haveeven entered a write busy stall because it attempted to write a newinitialization word to a busy DMAC), DMA₋₋ Rqst will not be deassertedin response to the final DMA₋₋ RdWrAck and the very next operation willbegin immediately. Therefore, external logic should check the state ofDMA₋₋ OpEnding to distinguish between DMA operation boundaries. Abenefit is that external logic can chose not to give up memory busownership if DMA₋₋ Rqst is not deasserted in response to the finaltransfer acknowledgment.

DMA₋₋ RdWrx

DMA Operation Type--Output--High/Rd, Low/Wr

When DMA₋₋ RdWrx is high and DMA₋₋ Rqst is high, the ATMizer 50's DMAEngine is initiating a memory read operation. If DMA₁₃ RdWrx is lowwhile DMA₋₋ Rqst is high, the ATMizer 50's DMA Engine is initiating amemory write operation. DMA₋₋ RdWrx remains valid throughout the entireDMA operation.

DMA₋₋ Drdy

DMA Data Ready--Output--Asserted High

Asserted by the DMA controller on memory write operations when writedata is valid on DMA₋₋ Data(31:0).

DMA₋₋ RdWrAck

DMA Read/Write Acknowledgment--Input--Asserted High

During memory read operations initiated by the DMA engine, externallogic asserts DMA₋₋ RdWrAck to indicate that it has placed valid dataonto DMA₋₋ Data(31:0). The DMA Engine samples the incoming data on therising edge of Clk if DMA₋₋ RdWrAck is asserted. During memory writeoperations, an external device asserts DMA₋₋ RdWrAck to indicate to theATMizer 50 that it has retired the present write operation and is readyfor the next address/data pair.

The ATMizer 50 will source the next address data pair off of the risingedge of Clk if DMA₋₋ RdWrAck is asserted at the rising edge of Clk.Transactions can be extended indefinitely by holding DMA₋₋ RdWrAckdeasserted.

If the acknowledged transfer was the last transfer of the operation,DMA₋₋ Rqst will be removed following the rising edge of Clk. During bothread and write operations the DMA Engine will respond to DMA₋₋ RdWrAckby incrementing the memory address by the appropriate number of bytes.

DMA₋₋ OpEnding

DMA Operation Ending--Output--Asserted High

Since the DMA controller 60 is capable of block transfers of up to 64bytes (16 words), the DMA₋₋ OpEnding signal is sourced during the lastmemory operation to indicate to the outside world that the operation isin its final transfer. This gives the memory controller warning that theoperation will end with the next DMA₋₋ RdWrAck returned to the ATMizer50.

The memory controller can use this warning to gain an early start on RASprecharge or to grant the bus to another master on the next cycle. DMA₋₋OpEnding will be removed following the rising clock edge upon which theATMizer 50 samples the final transfer acknowledgment (DMA₋₋ RdWrAckasserted) for the given DMA operation.

DMA₋₋ AdrOEx

DMA Address Bus Tristate Enable--Input--Asserted Low

When asserted (logical 0), the DMA₋₋ Address(31:2) outputs of theATMizer 50's DMA engine actively drive the memory address bus. Whendeasserted (logical 1), the DMA₋₋ Address(31:2) outputs are electricallyisolated from the memory address bus (tristated). Since the DMA enginedoes not have an explicit DMA Grant input, external logic can "Grant"the bus to the ATMizer 50 by turning on its address and data outputs.

DMA₋₋ DataOEx

DMA Data Bus Tristate Enable--Input--Asserted Low

When asserted (logical 0), the DMA₋₋ Data(31:0) outputs of the ATMizer50 actively drive the memory data bus. When deasserted (logical 1), theDMA₋₋ Data(31:0) outputs of the ATMizer 50 are electrically isolatedfrom the memory data bus (tristated). The ATMizer 50 will not drive theDMA₋₋ Data bus during read operations so the value of DMA₋₋ DataOExduring read operations is a "don't care".

DMA₋₋ Address(31:2)

DMA Memory Address Bus (31:2)--Output

The DMA Engine sources memory addresses on this bus during DMAoperations. These memory addresses can be used to access memory systemsor memory mapped devices giving the ATMizer 50 accessibility to allsystem components.

The ATMizer 50's DMA Engine always increments the DMA₋₋ Address inresponse to DMA₋₋ RdWrAck except on the last word of a DMA transfer.DMA₋₋ Address(31:24) is not incremented. Therefore, it is important thatuser firmware not initiate DMA operations that cross 16 megabyteboundaries.

DMA₋₋ Data(31:0)

DMA Memory Data Bus (31:0)--Bidirectional

During memory read operations, the DMA Engine samples DMA₋₋ Data(31:0)on each rising edge of Clk for which DMA₋₋ RdWrAck is asserted. Duringmemory write operations the DMA Engine sources data onto DMA₋₋Data(31:0). DMA₋₋ DataOEx should be asserted during memory writeoperations.

On Write operations the DMA Engine responds to DMA₋₋ RdWrAck by sourcingdata for the next transfer onto DMA₋₋ Data(31:0). DMA₋₋ Data(31:0) isnot changed following acknowledgment of the last transfer of the DMAoperation.

DMA₋₋ BMask(0:2)

DMA Write Data Bus Byte Masks--Output--Asserted High

On Write transfers, the DMA engine asserts one or more of the DMA₋₋BMask outputs to indicate which bytes contain valid data that must beretired to memory. Only those bytes should be written. DMA₋₋ BMask(0)pertains to DMA₋₋ Data(31:24), etc.

The DMAC does not clip byte masks on the far side of a word. For exampleat two byte write beginning at memory byte offset 00 would result inDMA₋₋ BMask(0:3) being asserted as 1111. A two byte Write operationbeginning at memory offset 01 would result in DMA₋₋ BMask(0:3) beingasserted as 0111. A six byte transfer starting a memory offset 10 wouldresult in DMA₋₋ BMask(3:0) being asserted for the first word as 0011 andfor the second word as 1111.

These examples show that the DMAC clips writes at the beginning toprevent overwriting valid data in on a partial word but does not (andneed not in almost every system implementation) clip byte writes at theend of a word. Therefore, DMA₋₋ BMask(3) is logically always assertedduring writes and therefore need not be supplied.

External devices should operate as if DMA₋₋ BMask(3) is provided andalways asserted on Write operations. On Read transfers, DMA₋₋ BMask(0:2)can be ignored. The accessed device always sources all four bytes onReads but only the desired bytes are sampled and stored by the DMAEngine.

DMA₋₋ GhostOp

DMA Ghost Write Operation--Output--Asserted High

In Scatter-Gather applications, it is possible that a single SAR SDU mayneed to be built from more than one memory based CS-PDU fragment andthat one of the fragments may not be of size divisible by four. Theresulting memory transfer operations may include non-aligned transfers,throwing the CRC32 generator off.

In such situations, firmware should build the fragment transition cellusing as many DMA operations as necessary. Once the SAR SDU is built inthe VCR 56, a ghost write operation is initiated by the APU 52 totransfer the SAR SDU through the CRC32 generator. External circuitry,seeing the DMA₋₋ GhostOp bit set, should ignore the transfer except toprovide the necessary number of DMA₋₋ RdWrAck assertions at the maximumrate possible to allow the DMA interface to cycle through the datatransfer in order to calculate the CRC32 partial or final result.

DMA₋₋ PLData

DMA Pipelined Read Data Indication--Input--Asserted High

Under normal operation, the data returned from memory during a memoryRead transfer is sent directly into the byte alignment circuitry priorto being latched. This adds to the data-setup-to-clock requirement forDMA₋₋ Data(31:0) but also removes one cycle of latency from theoperation. External circuitry can opt to have the data registered in theATMizer 50 immediately to reduce the setup requirement. This will add anadditional cycle of latency to the transfer.

In such a scenario, the DMA₋₋ RdWrAck must be withheld for one cycle.Asserting DMA₋₋ PLData causes DMA₋₋ Data(31:0) to be registered beforeentering the data alignment circuitry. The resulting reduction in setuptime will be reflected in the timing section of the specification.

PARALLEL CELL INTERFACE 62

TERMINOLOGY

The "Parallel Cell Interface" (PCI) 62 is the ATMizer 50 functionalblock that interfaces to the ATM Port side logic. Cells are created bythe ATMizer 50 from memory mapped CS-PDUS, Real Time Data Streams orfrom existing memory resident cells. These cell are "built" in cellholding areas inside the VCR 56. Once built they are transferred to theTransmission Convergence Sublayer framing circuitry one byte at a timethrough the PCI 62.

The PCI 62 contains special buffering circuitry to de-couple the ATMizer50's system clock frequency from the clock frequency required by theTransmission Convergence Sublayer framing circuitry. The PCI 62 isdriven by the ATM line-derived byte clocks.

The ATMizer 50 is designed to calculate and source HEC values in thefifth byte position of each cell. It is also designed to generate IDLEcells when no valid assigned cell is available for transmission. IDLEcell generation can not be inhibited. IDLE Cells must be fully ACK'edout of the PCI 62.

In ATM, raw cell data is combined with certain overhead information toform "transmission frames". The logic that accomplishes this framingbelongs to the Transmission Convergence Sublayer. ATM supports framingmodes that insert several framing bytes per "transmission frame". As aresult bytes will be received that do not correspond to data transfersbetween the TCS framing logic and the ATMizer 50's PCI ports.

As a result, data transfers to and from the ATMizer 50's PCI Ports willneed to be "Gappable". Therefore, there must be a way to signal to theATMizer 50 when no data transactions is desired. The two mechanism forimplementing this "Gapping" mechanism are:

1. Simply stop the PCI Port clock/s if a data transaction is notrequired due to framing overhead.

2. Deassert PCI₋₋ TxAck or PCI₋₋ RcAck to indicate that a datatransaction is not required due to framing overhead.

The former case corresponds to running the ATMizer 50's PCI Ports off of"Gapped clocks". The latter corresponds to running the ATMizer 50's PCIinterfaces off of the free running line clocks and using a ""data ready"mechanism" to deal with gapping. Both approaches are supported by theATMizer 50.

SIGNALS--TRANSMIT

PCI₋₋ TxData(7:0)

Parallel Cell Interface Data for Transmission--Output

The ATMizer 50 sources byte aligned cell data onto PCI₋₋ TxData(7:0).PCI₋₋ TxData(7:0) feeds the Transmission Convergence Sublayer framinglogic or, for 8B/10B encoding, PCI₋₋ TxData(7:0) could feed the Taxichip set directly. Logically, bit 7 is the first bit to be transmittedover the serial line.

PCI₋₋ TxSync

Parallel Cell Interface Transmitter Synchronizer--Input--Asserted High

PCI₋₋ TxSync is use to reset the state machines of the Transmitterinside of the ATMizer 50's Parallel Cell Interface. Asserting PCI₋₋TxSync will cause the Transmitter logic to discard the current cellbeing transmitted and begin sending the cell pointed to be the IDLE CellPointer inside of the PCI Transmitter 62a.

PCI₋₋ BOC and PCI₋₋ IDLECell will both be asserted following the removalof PCI₋₋ TxSync. If PCI₋₋ TxSync is issued in conjunction with Systemreset (Resetx) then no cell will be sent until the APU 52 enables thePCI Transmitter 62a by setting the "Cell Available" field inside of theATMizer 50's status register. Once the ATMizer 50 has set this field,PCI₋₋ TxSync will result in the transmission of the cell pointed to bethe IDLE cell pointer. The Transmitter synchronization process iscompletely decoupled from both System reset (Resetx) and Receiver reset(PCI₋₋ RcSync).

PCI₋₋ TxDrdy

Parallel Cell Interface Transmit Data Ready--Output--Asserted High

PCI₋₋ Drdy is of significance after the transmitter has been reset,either on System reset (Resetx) or on Transmitter reset (PCI₋₋ TxSync).Upon leaving either of these resets, data will become ready a number ofcycles later and the ATMizer 50 will assert PCI₋₋ TxDrdy and PCI₋₋ BOCto indicate that external logic can sample PCI₋₋ TxData(7:0) and issue aPCI₋₋ TxAck. External logic should not issue PCI₋₋ TxAck prior to seeingPCI₋₋ TxDrdy asserted.

Once asserted, PCI₋₋ TxDrdy remains asserted until the next System orTransmitter reset. This is a reflection of the fact that the ATMizer 50will always be ready to source data on PCI₋₋ TxData(7:0) (Assigned orUnassigned Cells) as long as the interface is operated at or below 25MHz (PCI₋₋ TxClk frequency).

PCI₋₋ TxAck

PCI Transmitted Data Acknowledgment--Input--Asserted High

PCI₋₋ TxAck is asserted by the Transmission Convergence Sublayer framinglogic when it has sampled the data value on PCI₋₋ TxData(7:0). TheATMizer 50 responds to PCI₋₋ TxAck by sourcing the next byte of theexisting cell or the first byte of the next cell (assigned or IDLE) ontoPCI₋₋ TxData(7:0).

If the next byte is the first byte of a new cell, the ATMizer 50 willalso assert PCI₋₋ BOC and possibly PCI₋₋ IDLECell in response to PCI₋₋TxAck. PCI₋₋ TxAck allows the PCI Transmitter 62a to operate in"Gappable" mode. The ATMizer 50's PCI Transmitter 62a can be gapped intwo fashions:

1. PCI₋₋ TxAck is permanently asserted, PCI₋₋ TxClk is occasionally shutoff.

2. PCI₋₋ TxClk is free running. PCI₋₋ TxAck is deasserted if externallogic is unable to sample the byte on PCI₋₋ TxData(7:0) in a givencycle. This is the recommended mechanism.

PCI₋₋ TxClk

Parallel Cell Interface Transmitter Clock--Input--Signals sampled onedge

The elastic byte buffer inside the Transmitter portion of the ATMizer50's Parallel Cell Interface is driven by PCI₋₋ TxClk. All datatransfers from the ATMizer 50 over PCI₋₋ TxData(7:0) are synchronized tothis clock. PCI₋₋ TxDrdy, PCI₋₋ BOC, and PCI₋₋ IDLECell are alsosynchronized to this clock.

Logic inside of the ATMizer 50 handles synchronization between theATMizer 50's system clock and the PCI Transmitter 62a's elastic databuffer circuitry which is sequenced off of PCI₋₋ TxClk. The systemdesigner need not worry about metastability at the Transmitter output.PCI₋₋ TxClk is the byte clock of the external transmitter and can beoperated at any frequency less than or equal to 25 MHz.

If external logic is not ready to sample PCI₋₋ TxData(7:0) on a risingedge of its byte clock, it can either inhibit the rising edge fromreaching PCI₋₋ TxClk or cause the PCI Transmitter 62a to extend thecurrent data cycle by deasserting PCI₋₋ TxAck. The later is thepreferred approach.

PCI₋₋ BOC

Beginning of Cell--Output--Asserted High

The PCI Transmitter 62a asserts PCI₋₋ BOC while the first byte of a cellis sourced on PCI₋₋ TxData(7:0). PCI₋₋ BOC is removed after the firstPCI₋₋ TxAck is received for a cell. PCI₋₋ BOC should be qualified withPCI₋₋ TxDrdy.

PCI₋₋ IDLECell

Idle Cell--Output--Asserted High

The PCI Transmitter 62a asserts PCI₋₋ IDLECell during the entire periodthat an IDLE cell is being sourced onto PCI₋₋ TxData(7:0). (53 Byteslong). Transmission Convergence framing logic that does not wish totransmit IDLE cells must still assert PCI₋₋ TxAck until PCI₋₋ IDLECellgoes away. (i.e. it must "ACK" out the entire IDLE cell).

SIGNALS--RECEIVE

PCI₋₋ RcData(7:0)

Parallel Cell Interface Data for Reception--Input

The ATMizer 50 receives byte aligned cell data on PCI₋₋ RcData(7:0).PCI₋₋ RcData(7:0) is fed from the Transmission Convergence Sublayerframing logic or, for 8B/10B encoding, PCI₋₋ RcData(7:0) could be fedfrom a Taxi chip set directly. Logically, bit 7 is the first bit to bereceived over the serial line.

PCI₋₋ RcSync

Parallel Cell Interface Receiver Synchronizer--Input--Asserted High

PCI₋₋ RcSync is use to reset the state machines of the Receiver 62binside of the ATMizer 50's Parallel Cell Interface 62. Asserting PCI₋₋RcSync will cause the Receiver logic to discard the current cell beingreceived and proceed as if the next byte of data latched into theATMizer 50 (PCI₋₋ RcAck asserted on rising edge of PCI₋₋ RcClk) is thefirst byte of a cell.

PCI₋₋ RcSync is used during the cell boundary delineation process.External logic (or the ATMizer 50's APU 52 with a bit of creative designwork) assumes a cell boundary and synchronize the ATMizer 50's receiver.Logic then monitors the ATMizer 50's PCI₋₋ HECError output. If HECerrors continue, it is assumed that a wrong cell boundary was chosen.External logic can then "slip a byte" and reassert PCI₋₋ RcSync.Eventually, this logic will yield a correct choice for cell boundary andPCI₋₋ HECError will no longer be asserted. The Receiver synchronizationprocesses is completely decoupled from system reset and from theTransmission process.

PCI₋₋ RcAck

PCI Receive Data Acknowledgment--Input--Asserted High

PCI₋₋ RcAck is asserted by the Transmission Convergence framing logicwhen it has sourced data onto PCI₋₋ RcData(7:0). The ATMizer 50 respondsto PCI₋₋ RcAck by sampling PCI₋₋ RcData(7:0) on the rising edge of PCI₋₋RcClk. PCI₋₋ RcAck allows the PCI Receiver 62b to operate in "Gappable"mode. The ATMizer 50's PCI Receiver 62b can be gapped in two fashions.

1. PCI₋₋ RcAck is permanently asserted, PCI₋₋ RcClk is occasionally shutoff.

2. PCI₋₋ RcClk is free running. PCI₋₋ RcAck is deasserted if externallogic is unable to supply a byte on PCI₋₋ RcData(7:0) in a given cycle.This is the recommended mechanism.

PCI₋₋ RcClk

Parallel Cell Interface Receiver Clock--Input--Signals sampled on edge

The elastic byte buffer inside the Receiver 62b of the ATMizer 50'sParallel Cell Interface 62 is driven by PCI₋₋ RcClk. All data transfersto the ATMizer 50 over PCI₋₋ RcData(7:0) are synchronized to this clock.Assertion of the PCI₋₋ HECError output is synchronized to this clock.Logic inside of the ATMizer 50 handles synchronization between theATMizer 50's system clock and the PCI's Receive data buffer circuitrypowered by PCI₋₋ RcClk.

The system designer need not worry about metastability at the Receiverinput. PCI₋₋ RcClk is likely to be the clock derived from the line dataand can be operated at any frequency less than or equal to 25 MHz. Ifexternal logic is not ready to source PCI₋₋ RcData(7:0) on a rising edgeof its byte clock, it can either inhibit the rising edge from reachingPCI₋₋ RcClk or simply deassert PCI₋₋ RcAck.

PCI₋₋ HECError

HEC Error--Bidirect--Asserted High

PCI₋₋ HECError acts as an output when HEC generation is enabled and asan input when HEC generation is disabled. The ATMizer 50 asserts PCI₋₋HECError when the HEC field (byte 5 of a cell) received does not equalthe HEC field calculated by the ATMizer 50 for the ATM Header received.When HEC generation is disabled, the ATMizer 50 checks the state of HECError while processing the first byte of a SAR PDU. If PCI₋₋ HECError isasserted, external logic has found an HEC error and the cell will bediscarded.

PCI₋₋ RcBuffHalf

Received Cell Holder Buffer Half Full--Output--Asserted

High The ATMizer 50 asserts PCI₋₋ RcBuffHalf whenever the Received CellBuffer is at least half full (based on its sized as set in the SystemControl Register). External circuitry can use this signal to know whento transfer cell buffering to a byte wide off chip SRAM operating as aFIFO and when to start reading stored cells back out of the SRAM andwriting them back into the ATMizer 50.

PCI₋₋ RcBuffover

Received Cell Holder Buffer Overflow--Output--Asserted High

The ATMizer 50 asserts PCI₋₋ RcBuffover whenever the internal ReceivedCell Buffer in the VCR 56 overflows. The PCI will stop writing new cellsinto the VCR 56 once the buffer fills and will simply discard any newcells that the Transmission convergence framing logic attempts to writeinto the Receiver in the PCI.

PARALLEL PORT 64

SIGNALS

PP₋₋ Address(3:0)

Parallel Port 64 Address--Output

Set by the APU 52 on Parallel Port 64 Read and Write Transfers. Bits(5:2) of CPUAddress(3:0) are latched and sourced on PP₋₋ Address(3:0)during parallel port read and write operations.

PP₋₋ Data(7:0)

Parallel Port 64 Data--Bidirectional

Sampled by the APU 52 on Parallel Port 64 Read transfers. Sourced by theAPU 52 on Parallel Port 64 Write transfers. The Parallel Port 64contains a one deep write buffer that drives PP₋₋ Data(7:0) during Writetransfers.

PP₋₋ Rqst

Parallel Port 64 Request--Output--Asserted High

Asserted by the ATMizer 50 when it has sourced a valid address on PP₋₋Address(3:0) and wants to perform a transfer using the parallel port.

PP₋₋ RdWrx

Parallel Port 64 Read/High, Write/Low--Output--High/Rd, Low/Wr

Used to qualify PP₋₋ Rqst. If PP₋₋ RdWrx is high while PP₋₋ Rqst isasserted, the ATMizer 50 is requesting a Parallel Port 64 readoperation. If PP₋₋ RdWrx is low while PP₋₋ Rqst is asserted, the ATMizer50 is requesting a Parallel Port 64 write operation. The Parallel Port64 will automatically disable the data output drivers on ReadOperations.

PP₋₋ AdrOEx

Parallel Port 64 Address Tristate Enable--Input--Asserted Low

When asserted, the PP₋₋ Address(3:0) drive the Parallel Port 64 Addressbus. When deasserted, PP₋₋ Address(3:0) is electrically isolated fromthe bus (tristated). PP₋₋ AdrOEx should be deasserted if the ParallelPort 64 Address Bus has been granted to an external device.

PP₋₋ DataOEx

Parallel Port 64 Data Tristate Enable--Input--Asserted Low

When asserted, PP₋₋ Data(7:0) actively drive the Parallel Port 64 Databus. When deasserted, PP₋₋ Data(7:0) is electrically isolated from thebus (tristated). PP₋₋ Data(7:0) is automatically deasserted by theParallel Port 64 during Read operations. The state of PP₋₋ DataOEx is a"don't care" during Read operations. It should be driven Low by externallogic during ATMizer 50 Write transfers over the parallel port.

PP₋₋ RdWrAck

Parallel Port 64 Read/Write Acknowledgment--Input--Asserted High

External logic asserts PP₋₋ RdWrAck during a Parallel Port 64 Readoperation when it has placed valid data on PP₋₋ Data(7:0). Externallogic can extend a read access indefinitely by withholding PP₋₋ RdWrAck.Withholding PP₋₋ RdWrAck will force the APU 52 to stall until PP₋₋RdWrAck is asserted. External logic also must assert PP₋₋ RdWrAck inresponse to a Parallel Port 64 Write operation.

External logic asserts PP₋₋ RdWrAck once it has retired the Write datasourced on PP₋₋ Data(7:0). After queuing a write transfer to the writebuffer in the parallel port, if the APU 52 attempts a second ParallelPort 64 operation before PP₋₋ RdWrAck is asserted it will enter a stallcycle until PP₋₋ RdWrAck is asserted.

MESSAGING

SIGNALS

ATMizer 50₋₋ Int

ATMizer 50 Interrupt--Input--Asserted High/Level Sensitive

External logic asserts ATMizer 50₋₋ Int when it wishes to gain theattention of the APU 52. Reasons to gain APU 52 attention includemessage passing (i.e. configure Transmit Channel, Activate CS-PDUsegmentation, Change Pacing Rates, etc.) and other user definedconstructs. The actual usage of this input is entirely userprogrammable. ATMizer 50₋₋ Int is not an interrupt in the classic sense.

Instead, it is connected to CpCond0 of the APU 52. APU 52 firmware cansample this signal whenever it wishes to determine if the host desirescommunication with the APU 52. Branch on CpCond0 TRUE, will allow theATMizer 50 to sense this signal. If asserted, the ATMizer 50 can thenread a value off of the Parallel Port 64 to get an indication of why thehost asserted ATMizer₋₋ Int.

In fact, a messaging system can be designed by the user/system architectwhere the eight bit value could act as an index to a jump table, thusencoding the action to be taken directly in the message.

Host₋₋ Int

Host Interrupt--Output--Asserted High

The ATMizer 50 asserts Host Interrupt when it wishes to affect an actionby the host. The usage of this signal is user defined but is likely tobe used as part of the messaging system. Error conditions, congestionproblems, CS-PDUs reassembled, and other conditions may prompt the APU52 to seek host action. The ATMizer 50's APU 52 asserts Host₋₋ Int bywriting to an on-board register. Host₋₋ Int remains valid for only onecycle and must be latched by external logic.

GP₋₋ Int1, GP₋₋ Int2

General Purpose APU 52 Interrupts 1 and 2--Input--Asserted High

GP₋₋ Int1 is connected to APU 52 interrupt 3, GP₋₋ Int2 is connected toAPU 52 interrupt 4. Software running on the APU 52 can choose to disableor enable interrupts as necessary.

GENERAL SIGNALS

SIGNALS

PRU₋₋ CountDisable

Pacing Rate Unit Count Disable--Input--Asserted High

The down counters associated with the eight "Peak Rate Pacing Counters"(PRPCs) 58a count down one tick every System Clock tick (Clk). Externallogic can slow or inhibit the counting process by asserting PRU₋₋CountDisable. Asserting PRU₋₋ CountDisable prior to the rising edge ofClk prevents the PRPCs 58a from counting down on that clock tick.

This feature can be used creatively in DS1/Real Time circuit emulationsituations as a short cut mechanism for informing the ATMizer 50 that a47 byte payload has been received and is ready for transmission. For aPRPC (Peak Rate Pacing Counter) 58a to be inhibited by PRU₋₋CountDisable, it must have been configured to be sensitive to the stateof this bit. Otherwise, the PRPC 58a will ignore PRU₋₋ CountDisable.

Clk

System Clock Input--Input

The Clk input runs the ATMizer 50 APU 52, DMA Controller 60, ParallelPort 64 and much of the logic in the Parallel Cell Interface 62. Clkdoes not however effect the transfer of byte data to or from the ATMizer50 over the Parallel Cell Interface. These transaction are controlled byPCI₋₋ TxClk and PCI₋₋ RcClk. Supported frequencies on Clk are expectedto be 33, 40 and 50 MHz. 16.5, 20 and 25 MHz memory systems can besupported by running the ATMizer 50's DMA interface at 1/2 frequency(assert DMA₋₋ RdWrAck every other cycle).

Resetx

System Reset--Input--Asserted Low

This is the master reset for the ATMizer 50. External logic shoulddownload firmware to the ATMizer 50 during reset. Reset also causes thePCI Transmitter 62a and Receiver 62b to be reset. PCI₋₋ TxDrdy will golow in response to reset and stay low until the APU 52 queues a cell fortransmission.

Reset1x

LAC and MAC Reset--Input--Asserted Low

Reset1x is used to reset the circuitry involved in downloading userfirmware into the IRAM 54. It should be deasserted prior to beginningthe process of writing firmware into the IRAM 54. Reset1x sets the LocalAddress Counter and Memory Address Counter and Registers to zero. Thesecounters are then incremented each time DMA₋₋ RdWrAck is asserted.

12.0 ATMizer 50 Interface Timing

A timing diagram for the ATMizer 50 interface is collectivelyillustrated in FIGS. 28a to 28g.

FIG. 28a is a diagram listing the interfacing timing signals. FIGS. 28band 28c illustrate the PCI Transmitter 62a Synchronization. FIG. 28dillustrates a DMA write operation. FIG. 28e illustrates a DMA readoperation. FIG. 28f illustrates a Parallel Port 64 write operation. FIG.28g illustrates a Parallel Port 64 read operation.

An Ethernet controller 80 embodying the present invention is illustratedin FIG. 29, and is fabricated as a single integrated circuit chip on asubstrate 82. The controller 80 comprises a plurality of networkinterface units or cores 84, which can be operated separately orinterconnected at one end, as illustrated, to form a hub.

The cores 84 are synchronously driven from a clock unit 86, whichincludes a phase locked loop PLL frequency multiplier 88. A 10 MHz inputsignal from a system master clock (not shown) is applied to one input ofa phase comparator 90 of the multiplier 88, the output of which is fedthrough a loop filter 92 and voltage controlled oscillator (VCO) 94 to abuffer 96. The scale factor of the PLL multiplier 88 is selected to beeight, whereby the frequency of pulses output from the VCO 94 to thebuffer is 80 MHz.

The output of the buffer 96 (80 MHz clock pulses) is applied to an 80MHz clock input of the first or leftmost core 84. Each core 84 comprisesan internal voltage divider (not shown) which divides the 80 MHz signalby 2, 4 and 8 to produce 40, 20 and 10 MHz clock pulses at outputsthereof. The pulse outputs of the first to third cores 84 are applied tothe pulse inputs of the second to fourth cores 84 respectively.

The 10 and 20 MHz outputs of the fourth core 84 are connected to the 10and 20 MHz inputs of the first core 84 through buffers 98 and 100respectively. The output of the buffer 98 is applied to the other inputof the phase comparator 90 to complete the phase locked loop.

As illustrated in FIG. 30, each core 84 comprises a media accesscontroller (MAC) 102 including the elements enclosed in a dashed linebox, and a serial interface adapter (SIA) 104 including the otherelements illustrated in the drawing. The MAC 102 is connected externallythrough lines which are collectively designated as 106, whereas the SIA104 is connected externally through lines which are collectivelydesignated as 108.

The cores 84 can be used independently of each other, with the lines 106leading to individual units such as computer workstations. However, thecontroller 80 is more useful with the lines 106 interconnected asillustrated in FIG. 29 to form a hub. The lines 106 can be furtherconnected to another network element such as a router (not shown). Thelines 108 are connected to other network elements through Ethernetinterfaces which are not shown in the drawing.

The entire controller 80 is fabricated on a single integrated circuitchip, with the cores being clocked synchronously by the clock unit 86.This forces the individual cores 84 to transmit and receive data in asynchronous manner through the lines 106 in the hub configuration, andenables a router or other element which is connected to the network nodeconstituted by the interconnected lines 106 to operate in a periodicmanner which is much more efficient than if the cores 84 were attemptingto communicate through the lines 106 in an unsynchronized manner atrandom intervals. This latter operation would occur if a separate clockunit were provided for each core 84, and each core 84 was clockedindependently as in the prior art.

The present arrangement by which the cores 84 are integrated on a singleintegrated circuit chip and driven synchronously by a single clock unit86 is advantageous in that only one clock unit 86 is required, ratherthan a clock unit for each core, and the that the synchronous operationgreatly facilitates the smooth operation of the controller 80 whenoperated as a hub.

As illustrated in FIG. 30, each core 84 is configured to provide thefunctionality stipulated by IEEE standard 802.3. Ethernet is a networkprotocol embodying this standard, which is more generically referred toas Carrier Sense with Multiple Access and Carrier Detect (CSMA/CD).

An input data signal DATA IN enters the SIA 104 through a data inputline 110 which is connected to a link test unit 112, a squelch unit 114and a phase locked loop unit 116. The link test unit 112 generates aLINK signal on a link test line 113 which indicates whether or not thecore 84 is connected correctly in circuit. The squelch unit 114distinguishes a valid DATA IN signal from noise, and provides an outputto a carrier deference unit 117 which is connected to a transmit engine118.

A collision signal COL is fed through a collision signal line 120 and acollision squelch unit 122 to a transmit backoff unit 124, the output ofwhich is applied to the transmit engine 118. The PLL unit 116 generatesa PLL signal on a PLL line 126 which indicates that the PLL unit 116 islocked on a signal.

The DATA IN signal is locked by the PLL unit 116 and applied to areceive engine 128, which receives a receive signal REC on a line 129. Areceive CRC unit 130 performs cyclic redundancy checks on data in thereceive engine 128, whereas a transmit CRC unit 130 performs thisfunction on data in the transmit engine 118.

Data from the transmit engine 118 is fed through an encoder 136 to adata output line 138 as a data signal DATA OUT. Data enters the transmitengine as a signal XMIT on a transmit line 140. The lines 110, 120 and138 constitute the line 108, whereas the lines 113, 126, 129 and 140constitute the line 106.

Data applied to the XMIT line 140 is received by the transmit engine,encoded by the encoder 136 and transmitted out through the line 138.Data received on the line 110 is decoded by the PLL unit 116, and fedout by the receive engine 128 through the line 129. If the line 108 isbusy, as indicated by a DATA IN signal on the line 110, the carrierdeference unit 117 inhibits the transmit engine 118 from transmittingdata until the line is clear.

The transmit backoff unit is responsive to a collision signal COL on theline 120, which indicates that two or more units are attempting totransmit on the network at the same time. In response to the signal COL,the transmit backoff unit 124 executes a truncated exponential backoffalgorithm as specified in IEEE 802.3. This algorithm utilizes a pseudorandom number generator to generate a random number which designates abackoff time, or a time for which the transmit engine 118 should waitbefore attempting transmission.

If all of the cores in the network utilize the same type of pseudorandom number generator, they will generate the same sequence of randomnumbers. If the random number generators of two or more cores becomesynchronized with each other, they will cause the associated cores toback off by the same times. This will cause the cores to continuouslyattempt to transmit at the same times. This condition is called"lockup", and can result in the cores generating collisionsindefinitely, preventing any data from being transmitted over thenetwork.

This problem is overcome by employing a pseudo random number generator142 in the transmit backoff unit 124 as illustrated in FIG. 31. Thegenerator 142 comprises a linear feedback shift register 144 including25 flip-flops 146 which are synchronously clocked by a 10 MHz clocksignal. Further illustrated is a chip reset signal which can be appliedto reset all of the flip-flops 146. The flip-flops 146 are designated inthe drawing as stages BIT 0 to BIT 24.

The flip-flops 146 are connected in a ring, with the outputs of upstreamflip-flops 146 being connected to the inputs of the adjacent downstreamflip-flops 146. The output of the 25th flip-flop 146 (BIT 24) isconnected through an exclusive NOR gate 148 to the input of the 1stflip-flop 146 (BIT 0).

The shift register 144 has two modes of operation, each operating on adivision ratio of 33,554,431, (2²⁵ -1). In each mode, the shift register144 generates the same random numbers, but in different orders. Thefirst mode appears at the output of the 18th shift register 146 (BIT17), whereas the other mode appears at the output of the 22nd shiftregister 146 (BIT 21). These mode outputs are connected to signal inputsof a multiplexer 150, the output of which is connected to another inputof the gate 148.

Each data packet being transmitted by the transmit engine 118 has aheader including a serial address. This address is applied serially (bitby bit) to an input of an AND gate 152, the output of which is connectedto a switch input of the multiplexer 150. The AND gate 152 is enabled bya TRANSMIT signal which is generated in the transmit backoff unit 124.

When the bit of the serial address being applied to the multiplexer 150is high, the multiplexer 150 will switch or gate the BIT 17 mode signalthrough the gate 148 to the BIT 0 input of the shift register 144. Whenthe bit is low, the multiplexer 150 will gate the BIT 21 mode signal tothe input of the shift register 144.

In this manner, the random number generator 142 is repeatedly switchedbetween its two operating modes, in accordance with the logical sense ofthe individual bits of the serial packet address, thereby increasing therandomness of the random numbers produced by the generator 142 by anenormous factor. This reduces the possibility of two or more coresattempting to transmit data after waiting the same backoff time after acollision to such a low level that it can be assumed for practicalpurposes that this condition and the resulting network lockup will neveroccur.

FIG. 32 illustrates a single chip device which can be configured as ahub, a bridge or a router depending on the types of interface unitsprovided. As illustrated, a single chip router 200 comprises a filterengine 202, a RISC CPU 204, an instruction RAM 206, a packet data RAM208, a direct memory access controller 210, a window filter 212, aplurality of packet attribute buffer memories 214, a plurality of LANmedia access interface units 216 and a WAN interface unit 218. Therouter 200 can be converted to a hub by omitting or not using the WANinterface unit 218. These units are interconnected as illustrated in thedrawing.

Each interface unit 216 comprises a buffer 220, a media accesscontroller 222, an encoder/decoder 224 and a 10BaseT interface 226. Theinterface unit 218 comprises a buffer 228, a serial controller 218, aframer 232 and a serial interface 234.

The CPU 204 controls all processing of data packets in the memory RAM208 including segmentation, reassembly, routing, address hashing andaddress filtering. The CPU 204 also utilizes the DMA controller 210 as aslave resource for transferring data packets from the memory 208 to andfrom the interfaces 216 and 218 using scatter and gather techniques. Theinstruction RAM 206 stores an operating program for the CPU 206 involatile or non-volatile memory.

The packet attribute buffers 214 store attributes of packets which areaccessed using the packet addresses. The filter engine 202 and CPU 204perform a non-linear hashing algorithm on the packet addresses foraccessing the corresponding attributes in the buffers 214 with reducedprocessing time and hardware. The window filter 212 further facilitatesattribute access by examining only predetermined portions of theaddresses rather than the entire addresses.

The combination of the non-linear hashing function and the window filterenable the router 200 to be fabricated on a single chip, eliminating theproblems with external memory access and latency which plague the priorart. These functions enable the data packets to be stored in the on-chipdata RAM 208, rather than in external CAM memory as in the prior art.

Typical Network topologies today make extensive use of Local AreaNetwork (LAN) traffic and "routing" of such LAN traffic over a Wide AreaNetwork (WAN). The node devices provide a desktop or terminal interfacefor traffic at speeds of up to 100 mbps. These nodes may be linkedtogether or individually instantiated. The linked units are typically 30to 50 per link, sharing the bandwidth of an individual "port" or MediaAccess Controller (MAC) and thus operating at a lower throughput due toshared bandwidth.

The hub provides the concentration and decision point for networktraffic that must be passed between "segments", with each segment beingrepresented by a unique port on the "port" or local side of the hub. Thehub decides whether to forward a packet to another node or out of theWAN port based on the attributes of that packet, or whether to "drop" ifthe address is a local one and will be therefore picked up by anothernode on that same segment.

Typical hub operation is therefore known as "physical layer"passthrough, as it simply works at the physical wire level, moving LANmode traffic from physical interface to physical interface as needed,wave shaping the signal and amplifying it if necessary.

The topology of providing a single node per MAC and switching thistraffic through the hub provides full bandwidth for that node,significantly improving performance for that individual node overconventional shared MAC topologies. By dedicating the Media AccessController to the port and providing for a single address and packetswitching fabric, a substantial performance gain can be attained.

A hub can terminate dozens of segments, however, each representing 30 to50 nodes, with each node being identified by a unique 48 byte staticaddress. As such the range of each address is 2⁴⁸, and the number ofaddresses terminated on a hub could be on the order of 1,000. Thistraffic level can congest a node to the point of saturation in apopulated LAN environment. By filtering LAN segment addresses and onlypassing through those as required to other segments, bridging can beperformed, greatly reducing traffic on each segment. This processoperates at the "data link" layer of the OSI network model and involveslearning the LAN topology in address tables and deciding on whether topass a packet through a bridge point, as it is destined for some othersegment, or dropping it, as it is destined for another user on the samelocal segment.

The nodes can represent various types of LAN traffic or communicationsstandards, all terminating on the hub. Typical LAN protocols includeEthernet (IEEE 802.3) and Token Ring (IEEE 802.5).

These LAN standards must often be routed out of the WAN to reach aremote hub or node, by utilizing a process known as routing. Thisprocess involves the following:

1. Mapping the LAN packet into a desired outgoing port format.

2. Attaching a routing address to the final destination.

3. Attaching an intermediate address to the next node in the mesh thatrepresents the optimal intermediate path to reach that node.

This process is currently accomplished by multiprotocol routers at theNetwork Layer, requiring substantially higher processing power than thehub or bridge. The entire process is reciprocated in the reversedirection.

Packet processing, address filtering and destination routing all requirea central processing unit. In accordance with the present invention,these functions are integrated on a signal chip. A single chip router orhub embodying the present invention includes the following elements.

A high performance RISC CPU 204 which operates at a speed of greaterthan 5\40 mips.

Multiple media access controllers 216 with full interface connectivity.

A direct memory access controller 210 with a Linked-List capability.

Wide area network ports 218.

A packet cache memory 208.

A packet address memory 214 with a non-linear search mechanism(hash/window filter.

A packet attribute table with learning capability.

SINGLE DEVICE IMPLEMENTATION--ELIMINATION OF DISCREET PERFORMANCEBOTTLENECKS

A hub or router conventionally comprises a LAN I/O subsystem, a WAN/ I/Osubsystem, DAM controller, central processing unit (CPU) and buffermemory all connected to a common system bus. The primary bottleneck isthe packet memory and I/O subsystem latency. In order to move trafficinto and out of the CPU, the latencies are introduced by chip to chipand memory delays. In order to quickly assembly and disassembly thevarious packet structures provided by these multiple standards, the CPUmust move traffic from the I/O subsystem to and from buffer memory andperform a variety of bit level manipulations on the traffic. This is thesecondary bottleneck in the conventional router architecture.

The incoming source and destination addresses must be matched with afilter/forward tree, and other attributes pertaining to security,protocol type, speed, etc. must be obtained. These can be done in alinear fashion at considerable time expense, or with a complex mechanismof Content Addressable Memories (CAM). Since the performance advantageobtained by embodying the entire system in a single chip is substantial,bringing this mechanism on-chip would be required.

This is not technically feasible. RISC architectures can be utilized toimprove the overall CPU performance, but the ability to bring the packetmemory on-chip with a more efficient packet access structure eliminatesthe latencies associated with off-chip packet access in conventionalDRAM technology. By also accommodating the I/O subsystem and memorycontroller, external accesses are virtually eliminated, significantlyimproving packet throughput.

ATTRIBUTE LOOK-UP/DECISION MAKING

Once a network configuration is learned by a typical router, therequirement to manipulate the entire address field is seldom required.As a matter of fact, of the 48 bits of address, as few as 12 bits needbe processed. By using a variable window filter on the packet memory,the access time for channel or packet attributes can be further reduced.

The nodes or segments terminating on a hub are similar in location, usergroup and/or matching type. By recognizing the fact that these addressfields will be similar in some respects, particularly in the mostsignificant bit fields, it is possible to substantially reduce theattribute look-up time by using the variable width window filter on thespecial RAM structure as illustrated in FIG. 33. This provides an entirerouting/bridging/filter decision to the CPU in the form of acomprehensive control word.

DYNAMIC WINDOW FILTER

A typical Data Link Layer Frame Format in the Ethernet format consistsof destination, source, type, data payload and frame check sequences.The window filter finds the maximum common address range for the activeaddresses terminated on the device by parsing the source packet addresstables at network configuration and as a backup task upon instantiationof a new address. Although this procedure is time consuming for thefirst pass, it substantially reduces packet attribute searches when donein real time.

The filtering process typically starts at the most significant bitfirst, and reduces the size of the window until a difference in incomingaddress bit field is found (FIG. 33). The architecture does not requirea separate memory for packet addresses, as this would consumeconsiderable space on the device. Instead, the packet window filteradjusts to the minimum size as incoming packet addresses are passedthrough the device. This packet address table can be stored off-chip inless costly DRAM for background access and window filter setup. Thiswindow filter feeds the hash-function dynamically or as instructed bythe CPU. This function utilizes the Packet Attribute memory byconfiguring it for the parameters required.

In the dynamic mode of operation, source address windows can be reducedfrom the 48 bit field to a considerably smaller number of entries. Inthe example of FIG. 33, a 16 bit unique field is identified and theentire Type field is utilized as the control word to instruct the CPUwhat to do with the packet. The CPU decision can be created while thepacket payload is being streamed as outlined by the command word in realtime.

The actual filter algorithm is run on the CPU so as to provide higherlevels of flexibility in choosing a particular algorithm for a specificnetwork topology.

STATIC WINDOW FILTER

As outlined above, the dynamic window filter sizes itself to thesmallest least common address window size. In specific routing orattribute environments, the window can be programmed to be a fixed sizeto greatly improve decision time. For example, encryptation orcompression of only addresses going to a certain destination range canbe triggered by filter memory locations based on a fixed window. Anexample of a static window filter is illustrated in FIG. 34, with anexample of the operation thereof illustrated in FIG. 35.

NON-LINEAR PACKET ATTRIBUTE LOOK-UP

Once the window size has been determined, access to packet attributescan be accelerated by the use of a non-linear algorithm running on theCPU. This also reduces the size of the packet attribute memory,facilitating the single chip solution. The CPU is passed a filter "key"in the form of a window under examination and the CPU implements thedesired filtering in the form of a hashing function. The CPU thenprovides the resultant address to the packet attribute memory (PAM) forstorage and subsequent retrieval.

CONTROL WORD PASS THROUGH

Instead of yielding a single decision as in a bridge (drop of forwardpacket) or a routing decision outcome, the entry in the PAM can providea complete control word to the CPU instructing it on what to do with thepacket.

HIGH SPEED PACKET BUILDING/MEMORY FRAGMENTING

Using a DMA controller to build packets in memory or move them quicklyfrom one buffer location to another is required. By construction, thepresent invention provides the system design with all of thefunctionality needed to implement a fully robust scatter-gather Deviceto Memory interface. In the gather direction (during packet building fortransmission), the invention is capable of generating cells from anynumber of separate data packets in memory as if they were a singlecontiguous packet.

By doing so, the invention precludes the need for the host processor todo a series of time consuming data movement operations to form acontiguous packet in a local buffer memory prior to initializing thetransmit operation. For example, in a TCP/IP application, the TCP/IPheader may reside in a different location within host memory from theactual user packet data payload. In addition, the actual packet datapayload field may actually consist of a number of discontinuous pages ofmemory. Because the invention supports "Gather" operations, there is noneed to move all of these data structures in advance into a singlepacket.

The actual implementation of both scatter and gather are defined in userfirmware running on the RISC CPU 204. In general, the gather functioncan be implemented by having the host processor pass to the invention aseries of "Segment Packet Fragment" messages with the appropriate userdefined control structures. The RISC CPU 204, recognizing that it isinvolved in a gather operation, is programmed not to generate end ofpacket header fields at the end of a packet fragment. It is alsoprogrammed to understand how to resolve the arrival at an end of apacket fragment boundary (i.e. automatically resolve the link listpointer or simply pass a message to the host processor asking it toresolve the next pointer for it).

Packets under segmentation need not be contiguous in system memory whenusing the invention. The segmentation and reassembly routines, writtenby the system designer and executed by the invention, can performsegmentation on non-contiguous data structures that logically form asingle packet. This is what is commonly referred to as the "gather"function of a scatter-gather DMA controller.

These user supplied routines handle packet and packet header generationand extraction as well as link list pointer management and bufferallocation. The implications of "scatter" and "gather" support, madepossible by the inclusion of a 32 bit RISC CPU 204, enable acceleratedpacket building so as to eliminate the newly created packetbuilding/memory scatter bottleneck.

In specialty applications, the invention can also perform the strippingof higher layer headers from incoming packets and placing them inspecific memory locations to aid network software. In addition, theinvention can utilize the powerful byte alignment capabilities of theDMA engine to ensure that the higher layer (Transport Layer) is writteninto memory on a word aligned basis. This releases application layersoftware from the responsibility of ensuring proper data alignment.

FIGS. 36 and 37 are architectural examples of the layout of componentsof a single chip router and a single chip hub respectively which arefabricated on an integral substrate in accordance with the abovedescribed principles of the present invention.

While several illustrative embodiments of the invention have been shownand described, numerous variations and alternate embodiments will occurto those skilled in the art, without departing from the spirit and scopeof the invention. Accordingly, it is intended that the present inventionnot be limited solely to the specifically described illustrativeembodiments. Various modifications are contemplated and can be madewithout departing from the spirit and scope of the invention as definedby the appended claims.

We claim:
 1. A random number generating apparatus for an interface unitof a Carrier Sense with Multiple Access and Collision Detect (CSMA/CD)data network, said interface unit including a first transmit backoffunit for implementing a backoff algorithm in response to a networkcollision signal and a random number, said apparatus comprising:a firstrandom number generator having first and second modes of randomizingsaid random numbers, and a multiplexer for selecting a random numberpertaining to one of modes in accordance with an address of a datapacket being processed by the interface unit, wherein said random numberaffects the time in which a packet is to be to re-transmitted, wherebyone of said first and second modes is selected to differ with anotherrandomizing mode of a second random number generator of a secondtransmit back-off time unit to prevent lock-up condition between saidfirst and second transmit back-off units.
 2. An apparatus as in claim 1,in which the multiplexer receives said address in the form of serialbits, and switches the random number generator between modes inaccordance with the logical senses of said bits.
 3. An apparatus as inclaim 1, in which the random number generator comprises a linearfeedback shift register.
 4. An apparatus as in claim 3, in which:theshift register has a plurality of stages; and the multiplexer has twosignal inputs connected to outputs of two of said stages respectively, aswitch input connected to receive said address and an output connectedin circuit to an input of the shift register.
 5. An apparatus as inclaim 4, in which:the shift register has 25 stages; and said signalinputs of the multiplexer are connected to stages 18 and 22 of the shiftregister respectively.
 6. A single-chip data controller, comprising:aplurality of cascaded network interface units including a first networkinterface unit, wherein the clock outputs of preceding interface unitsin the cascade are coupled to the clock inputs of succeeding networkinterface units in the cascade; and a clock unit for driving saidinterface units in synchronous with each other, said clock unit beingcoupled to said first network interface unit for supplying a clocksignal to said network interface units from said preceding interfaceunits to said succeeding interface units.
 7. A controller as in claim 6,in which:each interface unit is configured for interfacing in accordancewith the Carrier Sense with Multiple Access and Collision Detect(CSMA/CD) protocol, and includes a transmit backoff unit forimplementing a backoff algorithm in response to a network collisionsignal and a random number; and each interface unit comprises a randomnumber generating apparatus including:a random number generator havingfirst and second modes of randomizing said random numbers; and amultiplexer for selecting a random number pertaining to one of saidmodes in accordance with an address of a data packet being processed bythe interface unit, wherein said random number affects the time in whicha packet is to be to transmitted.
 8. A controller as in claim 7, inwhich the multiplexer receives said address in the form of serial bits,and switches the random number generator between modes in accordancewith the logical senses of said bits.
 9. A controller as in claim 7, inwhich the random number generator comprises a linear feedback shiftregister.
 10. A controller as in claim 9, in which:the shift registerhas a plurality of stages; and the multiplexer has two signal inputsconnected to outputs of two of said stages respectively, a switch inputconnected to receive said address and an output connected in circuit toan input of the shift register.
 11. A controller as in claim 10, inwhich:the shift register has 25 stages; and said signal inputs of themultiplexer are connected to stages 18 and 22 of the shift registerrespectively.